How do I route Sentry issue alerts about high latency to an AI SRE?

Tares receives Sentry issue alerts through the webhook connector and a Sentry integration setup. You then add a trigger that matches only the high latency symptom, so only those alerts wake your AI SRE agent. Tares has no connector of its own for Sentry today. Sentry signs each delivery, and Tares checks that signature.

How it works

Sentry reaches Tares through the webhook connector, not a dedicated Sentry connector. Sentry posts each delivery as JSON to the source’s ingest URL, and Tares stores the payload lossless.

• Authentication: Sentry signs every delivery with an HMAC signature in the Sentry-Hook-Signature header. The signature is the credential, so the source needs no Tares API key.
• Event type: action is a top-level payload field, so it can be the event_type_field. The resource is named in the Sentry-Hook-Resource header.
• Filtering: A trigger watches the Sentry source and applies a filter on a field. Only events that match the symptom count toward the condition, so only they fire the trigger.
• Waking the agent: The agent subscribes to that trigger. Alerts that do not match never reach it.

This follows the same pattern as the AI SRE guide. Prometheus keeps owning alerting there, and Tares ingests what fired and handles the waking. Here Sentry keeps owning the alert and Tares does the filtering and waking.

Set it up

1. Create the Tares source. In the console go to Sources → Add source → webhook, or ask a connected agent to create a webhook source. Use the signing options below, then copy the ingest endpoint from the source page. The signing options are described in the Tares release notes, not on the webhook connector page.

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

2. Add the integration in Sentry. Under Settings, Developer Settings, add an integration and set its Webhook URL to the Tares ingest URL. Subscribe it to the resources you want, such as issues or errors. Turn on Alert Action so alert rules can use it.

3. Copy the Client Secret. Paste the integration’s Client Secret into the Tares source as signing_secret.

4. Find the field that names the symptom. Let a few Sentry deliveries arrive. Open Recent events and Fields on the source page. Fields shows which payload fields arrive and how often. Pick the field whose value says what the alert is about, such as high latency. If you want the events on a service’s timeline, also add a service label read from the payload field that carries the service name, as in the AI SRE guide.

5. Create a trigger that matches only that symptom. Name the trigger after the symptom so each firing and each agent run is easy to recognize. Replace the field and value with what you found in step 4:

- name: sentry-high-latency
  sources: [sentry]
  filters:
    - { field: <field that names the symptom>, op: eq, value: high latency }
  condition: { aggregate: count, predicate: "> 0", window: 5m }
  cooldown: 10m

6. Subscribe your agent. Subscribe a Tares agent to sentry-high-latency, or point the trigger at your own agent service over a webhook or at a Slack channel. Write the agent’s prompt around latency so it knows why it woke.

7. Check it. When a matching Sentry alert arrives, open the trigger’s page and look under Firings. Alerts about other symptoms arrive as events on the source but add no firings.

What you get

• Only Sentry alerts that match the high latency symptom wake the agent. Other issue alerts are still stored on the Sentry source and stay readable.
• Each wake-up comes from a trigger named for the symptom, with its firings listed on the trigger’s page.
• Deliveries are authenticated by Sentry’s signature, so you manage no Tares API key for this source.
• The payload is stored lossless, so the full Sentry delivery stays available to the agent and to you.
• You can add more triggers on the same source, such as one for errors, each with its own filter, cooldown and agent.

When something else fits

• If the alert already comes from Prometheus or Alertmanager, use the alertmanager route in the AI SRE guide instead, since those have connectors of their own.
• If you want Tares to threshold a typed metric such as p99 latency directly, use a metrics source and a trigger condition on that field. A Sentry filter only reacts to alerts Sentry has already decided to send.
• If you need no filtering, route every Sentry alert to the agent with a trigger that has no symptom filter.

Related