How can an AI SRE see which values moved most during a cron job that stopped?

Tares gives an AI SRE the stats tool, which counts each value of one label in the current window against the window before and lists the largest change first. When a cron job stops, you see which values shifted most without reading a busy stream line by line. The agent can then open the values that moved with read.

How it works

By default a Tares agent has two tools, read and stats. Both go through the same Tares read path and cover the sources of the projects the run is for, unless the agent names other sources with sources.

• stats takes one label and returns the count for each of its values in this window and in the window before, ordered by the size of the change, largest first.
• read returns one correlated timeline for an entity.

On a busy stream, reading lines shows only the latest few, and those are rarely the ones that tell you what changed. stats summarizes the whole window instead. When a job stops, the values it used to produce change between the two windows, so they sort toward the top of the result.

The agent reads and concludes. By default it does not restart, deploy or ticket anything. If you connect external MCP tools to an agent, that boundary moves for that one agent only, and each run records the external tools it called. See Tools and MCP servers for the full description.

Set it up

1. Get the cron job’s output into a Tares source in the project the agent runs for. If the job writes to a container’s logs, a docker_logs source tails them. This example comes from the Docker logs connector:

- 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 }

2. Run an agent for that project. It has read and stats without any extra setup, and both cover the project’s sources. If the cron job lives in a source outside the project, name it with sources on the agent.
3. Ask the agent to compare the window where the job stopped with the one before it, and to use stats on a label that separates the things you care about, such as the service or the job name. Pick a label that your sources define.
4. Read the result from the top. The values with the largest change are the first candidates for what the stopped job affected.
5. Have the agent call read on the entity behind one of those values to get its correlated timeline and see what happened around the change.

The AI SRE guide shows how these reads fit into a full investigation.

What you get

• A ranked view of which values changed most between the window with the stopped job and the window before it.
• A summary that covers the whole window, not just the latest few lines of a busy stream.
• A direct path from a moved value to a correlated timeline through read.
• Read-only behavior by default, so the investigation does not change anything in your systems.

When something else fits

• If the stream is quiet and you need the exact lines around the moment the job stopped, use read for the entity’s timeline instead of stats.
• If you want the agent to act, such as restarting the job, connect an external MCP server and opt that agent in. Expect the agent to touch whatever the server exposes, and check the run’s record of the tools it called.

Related