How do I pair Sentry issue alerts with Grafana Loki logs for an AI SRE?

Tares pairs Sentry issue alerts with Grafana Loki logs when you give both sources the same service label. A firing alert then sits on one timeline next to the log lines from the same window. Sentry reaches Tares through the webhook connector and a Sentry integration, and Loki is read by the loki connector.

How it works

Tares builds one timeline per service from every source that carries the same service label. When two sources share that label, their events merge on one clock, and that merged read is what a trigger hands to an agent and what a connected client gets from read.

• Sentry issue alerts arrive as webhook posts. Tares has no connector of its own for Sentry today, so you use the webhook connector with a Sentry integration that points at the source’s ingest URL. Sentry signs each delivery, and Tares checks the signature with the integration’s Client Secret. The signature is the authentication, so the source needs no Tares API key.
• Loki logs come from the loki connector. It selects log lines with a LogQL query and polls every 5 seconds by default. It also works with Grafana Cloud. Its config keys include url, query, bearer_token, username, password and tenant_id.
• The shared key is a primary service label on both sources. Use the same label name and the same values on each side, such as checkout on the alert source and checkout on the log source.
• A trigger watches both sources and wakes your agent when an alert event arrives. This is the same pattern as the demo in Build an AI SRE, where alerts, logs and metrics all carry service and a trigger fires on the alert.

Set it up

1. Create the Sentry webhook source. In the console, go to Sources, Add source, webhook. Declare a primary service label. If the source covers one service, a constant works. If your payload carries the service in a field, read it with field instead. Save, then copy the ingest endpoint from the source page.

- name: sentry-issues
  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: checkout, primary: true }

The action field is top level in the Sentry payload, so it works as the event type field. The signing options are described in the Tares release notes, not on the webhook connector page.

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, and turn on Alert Action so issue alert rules can use it. Copy the integration Client Secret into the Tares source as the signing secret.

3. Create the Loki source. Add a loki source with your Loki url and your LogQL query. Add the credential keys your Loki needs, which are bearer_token, or username and password, plus tenant_id where it applies. Give it a primary service label with the same name and values you used for Sentry.

4. Check the fields. Once Sentry delivers an alert, open the source page. Recent events shows what arrived, and Fields shows which payload fields arrive and how often. Use it to confirm the service label is filled and to see the exact action value your alerts carry.

5. Add a trigger over both sources. Watch the two sources and fire when an alert event lands. Take the value for the filter from what you saw in Fields.

- name: sentry-alert
  sources: [sentry-issues, loki-logs]
  filters:
    - { field: event_type, op: eq, value: created }
  condition: { aggregate: count, predicate: "> 0", window: 1m }
  cooldown: 5m

6. Connect a client to read the pair. Start the MCP endpoint in a second shell.

tares mcp

Then ask your client what happened to your service in the last 15 minutes. It reads the merged timeline for that service, with the Sentry alert and the Loki lines together.

What you get

• One timeline per service that shows the Sentry issue alert beside the Loki log lines from the same window.
• A trigger that wakes an agent, or posts to your own agent service, when an alert arrives. The agent starts from the correlated evidence instead of querying Sentry and Loki separately.
• Authenticated Sentry deliveries, because the HMAC signature is checked against the Client Secret you copied into the source.
• Findings the agent writes back onto the same service timeline, so the next investigation starts from the last conclusion.

When something else fits

• If your alerts come from Prometheus or Alertmanager rather than Sentry, use the prometheus_alerts or alertmanager connector, which Tares has for those systems. The AI SRE guide walks through that wiring.
• If a Sentry payload carries no field you can map to a service, use one webhook source per service with a constant service label so the key still matches the Loki side.

Related