Skip to Content
Tares

How do I send an AI SRE’s finding about crash loops to my own automation?

Tares sends every finding an AI SRE agent records to your own automation through the write-back webhook. Each finding is POSTed as JSON, so a finding about a crash loop reaches your endpoint with its run metadata. Transient failures are retried, and the body never carries a key or token.

How it works

The write-back webhook is one of the Deliver findings options on an agent’s form, next to the Slack channel. It is a toggled row. When the toggle is on, Tares POSTs each finding the agent records to the URL you give it.

  • One POST per finding. When the agent records a finding about a crash loop, your automation receives it as a JSON body.
  • Finding and run metadata together. The body holds the finding text and details of the run that produced it: agent, trigger, key, run ID, dispatch ID, model, rounds, tool calls, start and finish times, duration and prompt hash.
  • Optional bearer token. If your endpoint needs authentication, you can set a bearer token. Tares sends it as an Authorization header on the request.
  • No secrets in the body. The body carries the finding and its run metadata, never a key or token.
  • Retries. Transient failures are retried. A failed delivery never loses the finding, because Tares has already stored it and it sits on the entity’s timeline.

Delivering a finding is not acting. The write-back webhook hands the finding to your automation, and your automation decides what to do with it. The agent’s own boundary stays the same. For the wider picture of how AI SRE agents investigate and record findings, see AI SRE.

Set it up

  1. Open the agent that investigates your crash loops and find the Deliver findings options on its form.
  2. Turn on the Write-back webhook row and enter the URL of your automation, such as a service or workflow endpoint that accepts a JSON POST.
  3. If that endpoint requires authentication, add the optional bearer token. Tares sends it as an Authorization header.
  4. Save the agent. Each new finding is now POSTed to your URL.
  5. Make your endpoint accept JSON and return a success status. Read the fields you need. A delivery looks like this:
{ "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" }
  1. Route on the fields. For example, use key to identify the entity the finding is about, agent and trigger to see which agent and trigger produced it, and finding for the note text to pass to a ticket, a chat message or a runbook step.

The full list of delivery options is on the Deliver findings page.

What you get

  • Every crash loop finding arrives at your automation as structured JSON, so you can open a ticket, page someone or start a remediation job without copying text by hand.
  • Run metadata comes with each finding: run_id, dispatch_id, model, rounds, tool_calls, started_at, finished_at, duration_s and prompt_hash. You can log it next to your own records and see how much work the agent did.
  • Authentication stays on your side. The bearer token you set goes in the Authorization header only, and the body never contains a key or token.
  • Delivery is dependable. Transient failures are retried, and a failing delivery never loses the finding, which is already stored on the entity’s timeline.
  • The agent stays inside its boundary. Your automation acts on the finding if you want it to, and the agent does not gain new powers from the delivery.

When something else fits

  • If people should read the finding in a chat channel, use the Slack channel option on the same form. The workspace bot posts the full finding to a channel you pick.
  • The older per-agent Slack incoming webhook still works, but it is neither retried nor logged and is used only when no channel is set, so prefer the Slack channel.
  • If you only need to read findings yourself, the entity’s timeline already holds every finding, so you do not need a write-back webhook.

Still stuck? Get help

Last updated on