How do I send an AI SRE’s finding about slow database queries to my own automation?

Tares sends each finding your AI SRE agent records about slow database queries to your own automation through the write-back webhook. Every finding is POSTed as JSON with run metadata, and the body never carries a key or token. Transient failures are retried, and the finding is already stored on the entity’s timeline, so a failed delivery never loses it.

How it works

Every finding lands on the entity’s timeline. The Write-back webhook option under the agent’s Deliver findings settings also sends it to a URL you choose. This is how a finding about slow database queries reaches a ticketing script, a chat bot or a runbook runner you own.

What the webhook does:

• One POST per finding. The body is JSON. The finding field holds the text the agent wrote, and the other fields describe the run: agent, trigger, key, run_id, dispatch_id, model, rounds, tool_calls, started_at, finished_at, duration_s and prompt_hash.
• Optional bearer token. If you set one, Tares sends it to your automation as an Authorization header, so your receiver can check who is calling.
• No secrets in the body. The payload carries the finding and its run metadata, never a key or token.
• Retries. Transient failures are retried. The finding is stored before delivery, so a failing receiver never loses it.
• Two event types. The webhook receives either a finding event or a skipped event.

Delivering a finding is not acting. Your automation decides what happens next. The agent’s own action boundary stays the same.

See Deliver findings for the full delivery options, and AI SRE for how the agent that writes the finding fits into Tares.

Set it up

1. Build an endpoint in your automation that accepts a POST with a JSON body. Decide whether it requires a bearer token.
2. Open the agent that investigates your slow database queries and find its Deliver findings options.
3. Turn on the Write-back webhook row and enter your endpoint URL. Add the bearer token if your endpoint expects one.
4. Save the agent. The next finding it records is POSTed to your URL.
5. In your receiver, read the event field first. For a finding event, the body 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"
}

6. Also handle the skipped event. It tells your receiver that a run a trigger dispatched was refused before it started, so you do not wait for a finding that never comes:

{
  "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 reason field is one of three values:

• daily_cap: the agent already ran its daily cap of runs in 24 hours.
• budget_exhausted: the agent used up its budget_usd.
• in_flight: a run of the agent for the same key is already going, and in_flight_run_id names it.

The key and labels fields name the firing the way a finding would. A rerun, a bootstrap run or a hand-off sends no skipped event.

What you get

• Each slow-query finding reaches your own system as structured JSON, ready to file a ticket, page someone or start a follow-up job.
• Run metadata arrives with every finding. You can use run_id, model, rounds, tool_calls and duration_s to audit how the agent reached its conclusion, and prompt_hash to tell which prompt produced it.
• The key field tells your automation which entity the finding is about, for example api-server.
• Retries on transient failures, and no lost findings, because the finding is stored on the timeline before delivery.
• A payload that is safe to log or forward, since it never contains a key or token.
• The skipped event lets a receiver that files findings per firing close out a run that was refused.

When something else fits

• If you want people to read findings where they already chat, use the Slack channel option. The workspace bot posts the full finding to a channel from the bot’s membership list.
• Avoid the older per-agent Slack incoming webhook URL for new setups. It still works, but it is neither retried nor logged, and it is used only when no channel is set.
• If you only need to read findings yourself, the entity’s timeline already holds every one, with no delivery setup.

Related