What should I look for in Docker container logs when a cron job has stopped?

Tares tails a container’s logs into one timeline per service, so a stopped cron job shows up as the point where its regular line stops appearing. Look for the last line the job printed, any error just before it, and what else changed on the service at that moment. Tares puts logs, metrics, alerts and deploys on one clock, and a connected agent reads that same timeline.

How it works

A cron job that stopped usually leaves no error. The sign is absence: the line it prints on each run no longer arrives.

The docker_logs connector tails a running container’s logs, one event per line, and keeps all lines by default. You narrow what you store with two optional regex filters:

• match keeps only lines that match, for example ERROR|WARN.
• drop skips lines that match, for example access logs.

When the job runs inside a container, the lines to look for are:

• The last normal line. Find the final time the job’s usual line appeared. The timestamp of that line is when the job stopped.
• Lines just before the gap. An error, warning or failure message right before the silence points at the cause.
• Silence after a restart. If the container restarted around the same time, check whether the job’s line came back afterwards.

Give the log source the same service label as your other sources. Tares merges every source that carries that label into one timeline per service, so the gap in the logs sits next to the metrics, alerts and deploy events from the same moment. Most real root causes are a change, so look for a deploy event near the last normal line.

A connected agent reads that same correlated timeline. It calls read with the service name and answers from the merged evidence, so you do not query each system by hand. When a trigger wakes a Tares agent, the agent starts with the timeline already in front of it. It writes a finding back onto the timeline: what broke, since when, the likely cause tied to evidence lines, and a next action. Open Explore and flip to What the agent gets to see the exact text an agent receives.

Set it up

1. Install the CLI and start Tares:

uv tool install tares          # or: brew install glassflow/tap/tares
tares up

2. Make sure taresd can reach the Docker daemon. Run taresd on the host, or mount the Docker socket and include the Docker CLI in the image.

3. Add a docker_logs source in the console under Sources → Add source → docker_logs, or ask a connected agent to find your containers and ingest the logs. Set container to the container name from docker ps. If the container runs under Compose, set compose_file so the tail follows restarts.

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

4. Set match on the source to a regex for your job’s output line if you want only those lines stored. Use drop to remove noisy lines such as access logs. This keeps the timeline readable around the gap.

5. Add a deploy source if you do not have one yet. A webhook source that your pipeline posts to on every deploy puts “deploy landed” on the same timeline as the gap. Give it the same service label.

6. Start the MCP endpoint in a second shell and point your MCP client at http://localhost:8788/mcp:

tares mcp

7. Ask your client about the service:

Use tares: what happened to api-server in the last 15 minutes?

8. Check the source in the console. Recent events shows lines on the next poll. If nothing arrives, check that taresd can run docker logs for that container.

The Docker logs connector page lists every field. Use AI to monitor your systems explains how sources, triggers and agents fit together, and Build an AI SRE walks through the full setup, including the triggers that wake an agent for you.

What you get

• A per-line record of the container’s output, so you can see exactly when the job’s line last appeared.
• Logs, metrics, alerts and deploys for the service on one clock, so a change next to the gap is easy to spot.
• An agent that reads the correlated timeline instead of making you open each system one at a time.
• Findings written back to the timeline, so the next investigation starts from the previous conclusion instead of from scratch.
• Regex filters on match and drop that keep the stored lines to the ones that matter for the job.

When something else fits

• If the cron job runs on a host outside Docker, docker_logs cannot see it. Send its output through another log path, such as OTLP, or post an event to a webhook source when the job finishes.
• If you need a page the moment a job misses a run, set up a trigger on the service. A trigger fires on a condition you choose and wakes an agent, which is described in Build an AI SRE.

Related