What should an AI SRE read next to Sentry issue alerts for 5xx errors on an API?

Tares puts the Sentry issue alert on the same per-service timeline as the API’s 5xx metrics, request logs and recent deploys, so an AI SRE reads all of it in one call. Sentry reaches Tares through the webhook connector and a Sentry integration setup, because Tares has no connector of its own for Sentry today. The agent then cites specific metric points, log lines and deploy events next to the alert instead of explaining the alert alone.

How it works

Sentry posts each delivery to a Tares webhook source. Tares stores the payload lossless and labels it with service. Metrics, logs and deploys for the same API carry the same service label, so they merge on one clock.

For a 5xx alert on an API, read these next to it:

• Metrics. The 5xx rate, p99 latency, database connections and dependency health, from a prometheus source. They show whether the error rate moved when the alert says it did.
• Logs. The API’s request logs, from a docker_logs source or your OpenTelemetry pipeline over OTLP. They show which requests failed.
• Alerts from your alerting stack. prometheus_alerts or alertmanager events, if you run them, so Sentry’s view and your own rules sit side by side.
• Recent changes. Deploy and config events from a webhook source, for example with event_type: deploy. Most root causes are a change, so a deploy landing shortly before the first 5xx is often the lead.

Sentry signs its deliveries, so the signature is the credential. You set signature_scheme to hmac_sha256, signature_header to Sentry-Hook-Signature and signing_secret to the integration Client Secret. The source needs no Tares API key. The action field is top level, so it can be the event_type_field.

Set it up

1. In Sentry, add an integration under Settings, Developer Settings. Set its Webhook URL to the Tares ingest URL from your webhook source.
2. Subscribe the integration to the resources you want, such as issues or errors, and turn on Alert Action so alert rules can use it.
3. Copy the integration Client Secret. It goes into the Tares source as the signing secret.
4. Create the Sentry source in Tares (Sources → Add source → webhook). The constant service label ties Sentry events to the API’s timeline. Use the same value your metrics and logs carry.

- name: sentry-api
  connector: webhook
  config:
    event_type_field: action
    signature_scheme: hmac_sha256
    signature_header: Sentry-Hook-Signature
    signing_secret: your-client-secret
    labels:
      - { name: service, const: api-server, primary: true }

5. Add the evidence sources, each keyed by the same service label: a prometheus source for the 5xx rate and latency, and docker_logs or OTLP for request logs.
6. Add a deploy source. Create a webhook source with a primary service label read from the payload’s service field, event_type: deploy, and a text template like deploy {commit} by {author}: {message}. Then send one request from your CD pipeline on every deploy:

curl -X POST https://<your-tares>/ingest/<ingest_key> \
  -H 'content-type: application/json' \
  -d '{"service": "checkout", "commit": "9f2c81d", "author": "dana", "message": "raise db pool size"}'

7. Start the MCP endpoint and connect your agent. The AI SRE guide walks through the full wiring.

tares mcp

8. Ask your agent: “Use tares: what happened to api-server in the last 15 minutes?” The client calls read with {"service": "api-server"} and answers from the correlated timeline. The webhook connector page covers labels, the text template and the Recent events and Fields checks, which show whether your Sentry deliveries arrive and how the fields map.

What you get

• One timeline for the API with the Sentry issue alert, the 5xx and latency metrics, the request logs and the deploys on a single clock.
• A diagnosis that cites evidence. The agent can say that errors started two minutes after a deploy and point to the failing log lines and the metric that moved.
• Your alerting stays where it is. Sentry keeps owning its alerts, and Tares ingests what fired and correlates it with the rest.
• Findings the agent writes back land on the same timeline, so the next investigation starts from the previous conclusion.

When something else fits

• If the Sentry alert is the only signal you have, the agent can report the alert but has nothing to compare it to. Add at least the metrics and the deploy source first.
• If your 5xx alerts already come from Prometheus rules or Alertmanager, ingest those with prometheus_alerts or alertmanager instead of adding Sentry as a second route.

Related