How do I test Sentry issue alerts about high latency before a real incident?

Tares lets you test Sentry issue alerts about high latency by posting a sample payload to the source’s ingest URL, then checking the label mapping and the event on the timeline. Sentry reaches Tares through the webhook connector and a vendor setup, and Tares has no connector of its own for Sentry today. For a push source, test_source takes no payload and only returns the ingest endpoint, so it does not check your labels. A sample post does, and you read the result in Recent events and Fields on the source page.

How it works

Sentry delivers issue alerts to a webhook source as JSON. Tares stores the payload lossless and maps the fields you declare as labels into the event.

• The Sentry payload has an action field, an installation object, a data object and an actor object. Sentry names the resource in the Sentry-Hook-Resource header.
• action is a top-level field, so it can be the event_type_field.
• text_template and event_type_field read top-level fields only. Labels can read one-level dotted fields such as actor.name.
• The signature is the credential for a real Sentry delivery. The source uses signature_scheme hmac_sha256, signature_header Sentry-Hook-Signature and a signing_secret set to the integration Client Secret.
• For a push source, test_source returns only the ingest endpoint. To check the mapping, post a sample payload and read Recent events and Fields.

Because a real Sentry delivery is signed, test the mapping on a scratch webhook source that has the same labels and no signing options. Then add the signing options to the real source.

Set it up

1. Create a scratch webhook source. In the console, go to Sources → Add source → webhook, or ask a connected agent to create a webhook source and give you the ingest URL. Declare the labels you want, and mark one primary.

- name: sentry-latency-test
  connector: webhook
  config:
    event_type_field: action
    text_template: '{action}'
    labels:
      - { name: installation, field: installation.uuid, primary: true }
      - { name: actor, field: actor.name }

2. Copy the ingest endpoint from the source page and post a sample shaped like a Sentry delivery.

curl -X POST http://localhost:8787/ingest/<ingest_key> \
  -H 'Content-Type: application/json' \
  -d '{"action": "created", "installation": {"uuid": "abc-123"}, "data": {}, "actor": {"type": "application", "id": 1, "name": "Sentry"}}'

3. Open the source page. Check Recent events for the event, with its event type taken from action. Check Fields to see which payload fields arrive and how often, and promote the ones you want to correlate on.
4. Adjust the labels and re-post until the mapping looks right. If you also want to correlate Alertmanager-style alerts, the Alertmanager connector fans out a batch into one event per alert and shows the same Recent events and Fields check.
5. Wire up the real source. In Sentry, add an integration under Settings, Developer Settings and set its Webhook URL to the Tares ingest URL. Subscribe it to issues or errors, and turn on Alert Action so your high latency alert rule can call it.
6. Copy the integration Client Secret into the Tares source as the signing secret, with signature_scheme hmac_sha256 and signature_header Sentry-Hook-Signature. These signing options are described in the release notes, not on the webhook connector page.
7. Trigger the high latency alert rule in Sentry once, for example from a staging project, and confirm that the same fields appear in Recent events.

The AI SRE guide shows how to turn these events into triggers once the mapping is right.

What you get

• You see how a Sentry-shaped payload becomes an event, with its event type, text and labels, before any real incident.
• You pick a reliable primary label from the Fields view instead of guessing.
• Your real source is signed with the Sentry Client Secret, and the alert rule for high latency reaches Tares through the same webhook source.
• Sentry issue events sit on the timeline next to your other sources, so you can correlate a latency alert with them.

When something else fits

• If you want one event per alert with Alertmanager’s grouping and resolved status, send the alerts through Alertmanager and use the Alertmanager connector instead.
• If you only need to check that Tares is reachable, a plain curl post to a scratch source is enough and you can skip the Sentry setup until you want the real signed delivery.

Related