Skip to Content

What should I do when an AI SRE run on a cron job that stopped ends as exhausted?

Tares ends a run as exhausted when the agent uses all of its model rounds before it can conclude, so raise max rounds for that agent. Set it under Advanced on the agent form or as max_rounds in catalog YAML, anywhere from 1 to 24. The run keeps the last text as a partial note, so you still get what the agent had worked out about the cron job that stopped.

How it works

A Tares agent is a prompt attached to a trigger. When the trigger fires, the agent reads the correlated timeline for the affected entity, can read a wider window or another entity, and writes a finding back. Each read and each tool call uses model rounds, and max_rounds caps them.

  • The cap. max_rounds accepts 1 to 24. Unset, the default is 6, or 12 once the agent uses external MCP servers, because a run that reads a diff or a file and writes back needs more than a read-and-conclude budget.
  • The last call. When the rounds run out mid-investigation, the model gets one final call with tools disabled so it can conclude from what it has already gathered.
  • The exhausted status. If the model still cannot conclude on that call, the run ends exhausted. Tares keeps the last text as a partial note and tells you to raise max rounds.
  • The record. Every run records the cap it was held to and shows rounds/max, so you can see how far the run got against its limit.

An exhausted run is recorded on the agent’s Runs list and does not appear as a finding on the entity’s timeline. Investigating a stopped cron job often means reading several windows and neighboring entities to find where the schedule broke. That kind of investigation spends rounds quickly on a low cap.

Set it up

  1. Open the agent’s page and go to Runs. Find the run with the exhausted status. Its rounds/max value shows the cap it hit.
  2. Read the partial note on that run. It holds the last text the agent produced, which often shows how far it got and what it still wanted to check.
  3. Raise max rounds. In the console, open the agent form, expand Advanced and set a higher value. Allowed values run from 1 to 24. If you manage the agent as catalog YAML, add max_rounds to it:
agents: - name: incident-first-look project: Default # optional; the project that made it trigger: incident # the trigger that wakes it enabled: true # on in its project max_rounds: 12 prompt: | You are an SRE taking the first look when an alert fires on this service. You are handed the correlated timeline: the firing alert plus the signals behind it and the request logs. Produce a tight incident note: what is failing and since when, the most likely cause tied to specific evidence lines, and a suggested next action. Do not speculate beyond the evidence.
  1. Wait for the next firing. The agent runs at most once per the trigger’s cooldown per entity, so a new run starts after the cooldown passes and the trigger fires again. Each agent also has a daily cap of 50 runs, set by TARES_AGENT_DAILY_CAP.
  2. Open Runs again and check the new run. It should end with a verdict or a finding instead of exhausted, and rounds/max shows how many rounds it needed. If it needed close to the cap, raise the cap a little more.

The Build an AI SRE guide walks the full loop of trigger, agent, run and finding if you want to see a run end to end.

What you get

  • A run on the stopped cron job that has enough rounds to read the timeline, check related entities and conclude, so the incident note lands on the entity’s timeline as a finding.
  • A visible record of every attempt. Each run shows its status, rounds against the cap, duration and errors, so you can tell whether a higher cap fixed the problem.
  • A partial note from the exhausted run, so the work done before the cap was hit is not lost while you adjust the setting.
  • A setting you control per agent. Other agents keep their own caps, and the 2,048 tokens per call and the daily cap stay as they are.

When something else fits

  • If the run ends exhausted even at 24 rounds, narrow the prompt so the agent checks fewer things, or split the work. A first agent can triage and hand off to a second one, with at most three handoffs in a row.
  • If a run fails rather than ends exhausted, the cause is different. Check the errors on the run in the agent’s Runs list, and confirm that a model provider is configured, because without one an enabled agent logs “no model provider” and writes no finding.

Still stuck? Get help

Last updated on