What should I look for in logs from Docker containers when the problem is failed deploys?

Tares tails a container’s logs with the docker_logs connector and puts them on the same service timeline as your deploy events. For failed deploys, look for the error and warning lines that start right after a deploy lands. Filter with match so those lines are what you read. An agent then reads the timeline and answers from it, so you do not scroll through raw lines yourself.

How it works

The docker_logs connector tails a running container’s logs and stores one event per line. It keeps all lines by default. You can narrow them with two optional regex filters:

• match keeps only lines that match, for example ERROR|WARN.
• drop skips lines that match, for example HTTP/1.1" to drop access logs.

For a failed deploy, these are the lines worth keeping:

• Error and warning lines from the container that was just deployed.
• The first error line after the deploy event. The timing matters more than any single message. A timeline that shows a deploy at 14:02 and errors from 14:04 points at the change.
• Lines from the container that appear after it restarts. If the container runs under Compose, set compose_file so the tail follows restarts.

To see the deploy next to the logs, give every source the same service label. Tares merges sources with the same label into one timeline per service. Most real root causes are a change, so add a deploy source as well. Use AI to monitor your systems covers this. A webhook source that your CD pipeline posts to on every deploy lands each deploy as an event on that service’s timeline.

An agent reads that merged timeline instead of making you query each system. A connected MCP client reads the timeline and answers from it. If you want a diagnosis written down automatically, a trigger on the service can wake a Tares agent or your own agent service. That agent writes what broke, since when, the likely cause tied to evidence lines and a next action onto the timeline.

Set it up

1. Install Tares and start it. Docker daemon access is required, so run taresd on the host, or mount the Docker socket and include the Docker CLI in the image.

tares up

2. Add the log source under Sources → Add source → docker_logs. Set container to the container or compose service name. Discover lists running containers to pick from. You can also ask a connected agent to find your running containers and ingest the api-server’s logs. It calls discover_docker, then test_source as a dry run, then create_source.
3. Keep the lines that matter for deploys with match, and give the source a primary service label.

- name: logs
  connector: docker_logs
  poll: 5s
  config:
    container: tares-demo-api-server   # the container name (docker ps)
    match: ERROR|WARN
    labels:
      - { name: service, const: api-server, primary: true }

4. Add a deploy source with the same service label. Create a webhook source and post to its ingest URL from your pipeline on every deploy.
5. Verify in the console. Recent events on the source shows lines on the next poll. If nothing arrives, check that taresd can run docker logs on the container.
6. To investigate interactively, start the MCP endpoint in a second shell and connect your client.

tares mcp

7. Ask the client what happened to the service in the last 15 minutes. It answers from the correlated read of the service’s timeline, including the deploy event and the log lines around it. Build an AI SRE walks through this end to end, including the trigger that wakes an agent.

What you get

• One timeline per service, with a deploy event and the container’s error and warning lines on the same clock.
• Only the lines you care about, because match and drop filter noise such as access logs before they reach the timeline.
• Container logs that keep flowing across restarts when you set compose_file for Compose services.
• Answers about a failed deploy that start from the correlated timeline. You do not query each system first.
• Optionally, a finding written onto the timeline by a woken agent. It names what broke, since when and the likely cause, tied to evidence lines, so the next investigation starts from that conclusion.

When something else fits

• If your logs already flow through OpenTelemetry or Vercel, use the OTLP or Vercel connector for that signal instead of tailing a container.
• If the failed deploy never starts a container, the deploy event itself is your evidence. Use the GitHub or webhook source for it.
• If you want Prometheus to keep deciding when something is wrong, keep it that way. Tares ingests what fires and correlates it with these logs.

Related