How do I test Sentry issue alerts about failed deploys before a real incident?

Tares lets you test Sentry issue alerts about failed deploys by posting a sample payload to a webhook source’s ingest URL and reading the result on the source page. Sentry reaches Tares through the webhook connector and a vendor setup, and Tares has no connector of its own for Sentry today. Check the label mapping under Fields and the event under Recent events, then add the Sentry signing options for the real source.

How it works

Sentry delivers issue alerts to Tares as HTTP POSTs. You turn them on in Sentry with an integration whose Webhook URL is the Tares ingest URL and whose Alert Action is on, so alert rules can call it. The webhook connector stores each payload lossless and maps the fields you declare as labels into the event.

For a push source, test_source takes no payload and only returns the ingest endpoint, so it does not check your label mapping. To test the mapping, post a sample payload yourself and read the source page.

• Recent events shows the event Tares stored for your sample, on the timeline with your other sources.
• Fields shows which payload fields arrive and how often, so you can pick a reliable key.
• Sentry’s payload has action at the top level, so it can be the event_type_field. The resource is named in the Sentry-Hook-Resource header.

For the real source, Sentry signs each delivery. You set signature_scheme to hmac_sha256, signature_header to Sentry-Hook-Signature and signing_secret to the integration Client Secret. The signature is the authentication, so the source needs no Tares API key.

Set it up

Test the mapping on a separate webhook source first, then configure the signed one. This keeps your experiments away from the source Sentry will use. For the wider picture of how alerts feed investigations, see AI SRE.

1. In Sources → Add source → webhook, create a test source with labels for the fields your Sentry payload carries. Mark one label primary.

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

2. Save the source and copy the ingest endpoint from the source page.
3. Post a sample shaped like a Sentry delivery. Put a marker of your own in data, such as a note that this is a failed deploy test.

curl -X POST http://localhost:8787/ingest/<ingest_key> \
  -H 'Content-Type: application/json' \
  -d '{"action": "created", "installation": {"uuid": "test-install"}, "data": {"note": "sample failed deploy"}, "actor": {"type": "application", "name": "sentry"}}'

4. Open Recent events and confirm the event carries the event type created and your labels. Open Fields and check that each field you mapped arrives. Adjust the labels and post again until the mapping is right.
5. Create the real source with the same labels and the Sentry signing options. Set signing_secret to the integration Client Secret.

- name: sentry
  connector: webhook
  config:
    event_type_field: action
    signature_scheme: hmac_sha256
    signature_header: Sentry-Hook-Signature
    signing_secret: <Client Secret>
    labels:
      - { name: installation, field: installation.uuid, primary: true }

6. In Sentry, open Settings, Developer Settings and add an integration. Set its Webhook URL to the real source’s ingest URL. Subscribe it to the resources you want, such as issues or errors, and turn on Alert Action.
7. Point an issue alert rule for your deploy failures at the integration. When the rule fires, check Recent events on the real source the same way you checked the test source.

The signing options are described in the Tares release notes, not on the webhook connector page.

What you get

• A label mapping you have already seen working, so the first real failed-deploy alert lands with the labels you expect.
• A sample event on the timeline that proves the ingest URL, the event type and the text template before an incident.
• A field list that shows which Sentry payload fields arrive, so you pick a primary label you can rely on.
• A signed production source where the Sentry signature is the credential, kept apart from the unsigned test source.

When something else fits

• If your failed-deploy signal reaches you through Alertmanager rather than Sentry, use the alertmanager connector. Its source page gives a sample batch you can post the same way.
• If you want to confirm the whole path from Sentry itself, fire a real issue alert rule from Sentry after the sample test passes.

Related