How can an AI SRE see which values moved most during crash loops?

Tares gives an AI SRE the stats tool, which counts each value of one label in this window against the window before and lists the largest change first. During a crash loop that ranking shows which values jumped, so the agent starts from the biggest movers instead of reading lines. Every Tares agent has stats by default, so there is nothing to switch on.

How it works

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

The stats tool works on one label at a time:

• It counts how often each value of that label appears in the current window.
• It counts the same values in the window before.
• It returns the values ordered by change, largest first.

This suits a busy stream better than reading lines. A crash loop can produce a lot of events, and reading them line by line would show only the latest few. The ranked counts show where the change is, whatever the volume.

read complements stats. It returns one correlated timeline for an entity. A common pattern is to use stats to find the value that moved most, then use read on that value’s entity to see what happened around it.

The agent can also end its run with the conclude tool. If a project has skills, the agent also gets the skill tool to load one skill’s instructions by name. The full list of tools is on the Tools and MCP servers page, and the wider approach to incident work is in AI SRE.

Set it up

1. Open the agent for your project. stats is already one of its default tools, so you do not enable it.
2. Decide which label you want ranked, such as service. Sources declare labels in their config. This container logs source declares a service label, for example:

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

3. If the crash-looping services send data to sources outside the projects the run is for, name those sources with sources on the agent. Otherwise the agent reads the sources of its own projects.
4. Ask the agent which values of that label changed most during the crash loop. It calls stats on the label and gets back the values ranked by change against the window before.
5. Ask it to follow up on the top value. The agent uses read to pull the correlated timeline for that entity and conclude to end the run with its findings.

What you get

• A ranked list of label values, largest change first, so the agent sees the biggest movers during a crash loop straight away.
• A comparison of this window with the window before, so a value that was already noisy does not look new.
• A view that stays useful on a busy stream, where reading lines would show only the latest few.
• A path from the ranking to the evidence. read gives the correlated timeline for the value that stands out.
• The same behavior for every agent, since stats is a default tool and draws on the same Tares read path as read.

When something else fits

• Use read when you already know the entity and want its correlated timeline rather than a ranking.
• By default an agent reads and concludes, and it does not restart or deploy anything. If you want it to act, register an external MCP server and opt the agent in on its form under External tools. Its tools then appear alongside read and stats, prefixed by the server name, and each run records which external tools it called.
• Use skills when you want the agent to follow written instructions for a recurring kind of incident.

Related