Skip to Content
Tares

Does Tares need a public URL to receive Sentry issue alerts?

Yes, Tares needs an ingest URL that Sentry can reach, because Sentry pushes issue alerts to Tares instead of Tares polling Sentry. Sentry reaches Tares through the webhook connector and a Sentry integration setup, since Tares has no connector of its own for Sentry today. The signature Sentry attaches to each delivery is the credential, so the source needs no Tares API key.

How it works

Tares has two ways to get data in. A polled source, such as the Prometheus connector, runs inside Tares and reaches out to the system on an interval. That needs no inbound URL on your side. A pushed source works the other way: the sender posts to Tares, so the sender must be able to open a connection to your instance.

Sentry is a pushed source. The pieces are:

  • Sentry integration. You add an integration in Sentry and set its Webhook URL to the Tares ingest URL, /ingest/ followed by the source’s ingest key.
  • Webhook source in Tares. A webhook source accepts the JSON, stores the payload lossless and maps the fields you declare as labels.
  • Signature check. Sentry signs each delivery. Tares checks the signature with the integration’s Client Secret, so the signature is the authentication.

A Tares you start with tares up serves the console and ingest on http://127.0.0.1:8787. That address is reachable only from your own machine, so Sentry cannot deliver to it. To receive Sentry alerts, give Tares a hostname that Sentry can reach. The compose setup on the deployment page runs Tares behind a Caddy reverse proxy with automatic HTTPS on a domain you choose, and routes everything except the MCP paths to the daemon. Your ingest URL is then that hostname followed by /ingest/ and the ingest key.

Set it up

  1. Run Tares on a host that Sentry can reach, using the server setup on the deployment page. For a quick local trial, start it with the command below, then expose it before pointing Sentry at it.
tares up
  1. In Tares, add a source with the webhook connector (Sources → Add source → webhook). Set the signing options, mark one label as primary, and save. Copy the ingest endpoint from the source page. action is a top-level field in the Sentry payload, so it can be the event type field.
- name: sentry-issues connector: webhook config: event_type_field: action signature_scheme: hmac_sha256 signature_header: Sentry-Hook-Signature signing_secret: <integration Client Secret> labels: - { name: action, field: action, primary: true }
  1. In Sentry, open Settings, then Developer Settings, and add an integration. Set its Webhook URL to the Tares ingest URL from step 2.
  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 into the Tares source as the signing secret, as in the yaml above.
  4. Trigger an issue in Sentry, then open the source in Tares and check Recent events. Fields shows which payload fields arrive and how often, which helps you pick labels.

Sentry names the resource in the Sentry-Hook-Resource header. The body carries action, installation, data and actor. The signing options are described in the release notes, not on the webhook connector page.

What you get

  • Sentry issue alerts arrive in Tares as events, with the full payload stored lossless.
  • Labels you declare map payload fields into the envelope, so you can correlate Sentry alerts with the rest of your sources.
  • Deliveries are authenticated by Sentry’s HMAC signature, so you do not mint or hand out a Tares API key for this source.
  • You can build AI SRE workflows over those events once they land, the same as for any other source.

When something else fits

  • If you cannot give Sentry a reachable address, Sentry alerts will not arrive, because Tares has no polled Sentry connector. Tares sources that poll, such as Prometheus alerts, reach out from Tares and need no inbound URL.
  • If you only want to try the webhook connector without Sentry, post a sample payload with curl to a local instance, as the webhook connector page shows.

Still stuck? Get help

Last updated on