How do I send an AI SRE’s finding about a disk filling up to my own automation?

Tares sends each AI SRE finding to your own automation through the write-back webhook, which POSTs it as JSON. A finding about a disk filling up arrives with its run metadata and never carries a key or token. Transient delivery failures are retried, and the finding stays stored on the entity’s timeline either way.

How it works

Every finding lands on the entity’s timeline. The agent’s Deliver findings options also send it where people and systems already look, and the write-back webhook is the one that targets your own automation. You can read more on the Deliver findings page, and the wider picture is in AI SRE.

When the agent records a finding, Tares POSTs it to your URL as JSON. The body holds two things:

• The finding itself, in the finding field. For a disk filling up, this is the note the agent wrote about it.
• The run metadata: the agent name, the trigger, the entity key, the run and dispatch IDs, the model, the number of rounds and tool calls, start and finish times, the duration and a prompt hash.

The body never carries a key or token, so your automation receives the finding and nothing sensitive from Tares.

Transient failures are retried. A failed delivery never loses the finding, because it is already stored before delivery is attempted.

Set it up

1. Prepare an endpoint in your automation that accepts a POST with a JSON body. It can be a runbook runner, a ticket creator or a paging bridge.
2. Open the agent that investigates the disk alert and find its Deliver findings options.
3. Switch on the Write-back webhook row and enter your endpoint URL.
4. If your endpoint needs authentication, add the optional bearer token. Tares sends it as an Authorization header on each delivery.
5. Trigger the agent, or wait for its trigger to fire, and check that your endpoint receives a body shaped 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"
}

6. In your automation, read event to confirm it is a finding. Use key to identify the entity, such as the host or service with the full disk. Read finding for the agent’s note. Store run_id and dispatch_id so you can tie the delivery back to the agent run.

What you get

• Every finding about a disk filling up reaches your automation as structured JSON, so you can parse it without scraping text.
• Run metadata comes with each finding: which agent, which trigger, which entity, which model, how many rounds and tool calls, and how long the run took.
• The body never carries a key or token, so you can log or forward it safely.
• Transient failures are retried, and the finding is still on the entity’s timeline if your endpoint is down.
• Delivering a finding is not acting. The write-back webhook passes the finding to your automation. Any action on the disk is something your automation decides to do, and the agent’s boundary stands.

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 from the bot’s membership list.
• The older per-agent Slack incoming webhook still works, but it is neither retried nor logged, and it is used only when no channel is set. Prefer the channel.

Related