How do I send an AI SRE’s finding about a cron job that stopped to my own automation?

Tares POSTs every AI SRE finding, including one about a cron job that stopped, as JSON to your own automation through the write-back webhook. The body carries the finding text and the run metadata, and it never carries a key or token. Transient failures are retried, and a failed delivery never loses the finding, because Tares has already stored it on the entity’s timeline.

How it works

Every finding an agent records lands on the entity’s timeline first. The agent’s Deliver findings options then send it where people and systems already look. The write-back webhook is one of those options, next to the Slack channel. The AI SRE guide shows where findings come from, and Deliver findings covers every delivery option.

When the agent finishes a run on a cron job that stopped, Tares sends one POST to your URL with a JSON body:

• event is finding.
• agent, trigger and key name the agent, the trigger that fired and the entity the finding is about.
• finding holds the note the agent wrote.
• run_id, dispatch_id, model, rounds, tool_calls, started_at, finished_at, duration_s and prompt_hash describe the run.

If you set a bearer token, Tares sends it as an Authorization header on the request. The token is never part of the body. The body never contains a key or token either.

Your receiver can also get a second event, skipped. It tells you that a run a trigger dispatched was refused before it started, so your automation does not wait for a finding that never comes. The reason field says why:

A rerun, a bootstrap run or a hand-off sends no skipped event.

Set it up

1. Open the agent that watches your cron job and find its Deliver findings options.
2. Turn on the Write-back webhook row and enter the URL of your own automation.
3. Add a bearer token if your receiver checks one. Tares sends it as an Authorization header.
4. Make your receiver accept a POST with a JSON body and branch on the event field. Handle finding and skipped.
5. Use key to match the finding to the entity, and run_id to tie it to the run that produced it.

A finding about a stopped cron job reaches your receiver in this shape:

{
  "event": "finding",
  "agent": "incident-first-look",
  "trigger": "incident",
  "key": "api-server",
  "finding": "…the incident note…",
  "run_id": "run_9f2c81d4a6b3",
  "dispatch_id": "c0f35f8210…",
  "model": "claude-sonnet-4-6",
  "rounds": 2,
  "tool_calls": 3,
  "started_at": "2026-08-14T12:01:03+00:00",
  "finished_at": "2026-08-14T12:01:35+00:00",
  "duration_s": 32.6,
  "prompt_hash": "1c9f2d"
}

The agent name, trigger and key in your payload are the ones of your own agent and entity. The values above are an example.

A refused run reaches your receiver as a skipped event:

{
  "event": "skipped",
  "reason": "in_flight",
  "message": "a run of this agent for the same key is already in flight",
  "agent": "incident-first-look",
  "trigger": "incident",
  "key": "api-server",
  "labels": {},
  "run_id": null,
  "dispatch_id": "c0f35f8210…",
  "in_flight_run_id": "run_9f2c81d4a6b3"
}

The message field carries the text the run records. The key and labels fields name the firing the way a finding would.

What you get

• Each finding about the stopped cron job arrives in your automation as structured JSON, so you can open a ticket, page someone or start a restart workflow from it.
• The run metadata, such as run_id, model, rounds, tool_calls and duration_s, travels with the finding, so you can trace or audit the run.
• Transient delivery failures are retried. If a delivery still fails, the finding is not lost. It is already stored on the entity’s timeline.
• Your receiver never sees a key or token in the body. Authentication is a separate bearer token in the Authorization header, and it is optional.
• skipped events tell your automation when a dispatched run was refused, so it does not wait for a finding that never comes.
• Delivering a finding is not acting. The agent’s boundary stands, and your automation decides what happens next.

When something else fits

• If people should read the finding, use the Slack channel option. The workspace bot posts the full finding to a channel you pick.
• The older per-agent Slack incoming webhook URL still works, but it is neither retried nor logged, and Tares uses it only when no channel is set. Prefer the channel.

Related