How do I add Postgres tables to the evidence an AI SRE reads when Sentry issue alerts fire?

Tares lets you add a Postgres table as a second source next to your Sentry issue alerts, so an AI SRE reads rows that show who or what an incident touched. Sentry reaches Tares through the webhook connector and a Sentry-side setup, and the table comes in through the postgres connector, which polls it for new and changed rows. Both land on the same timeline, so you can read the alert and the matching rows together.

How it works

Tares has no connector of its own for Sentry today. Sentry calls Tares through the webhook connector. You add an integration in Sentry, point its Webhook URL at a Tares ingest URL, and Tares stores each payload lossless as an event.

Sentry signs its deliveries. The signature is the credential, so the Tares source holds the integration Client Secret as its signing secret and needs no Tares API key.

The Postgres side works the other way round. The Postgres connector polls a table incrementally and writes one event per new or changed row. A cursor column that only grows, such as an autoincrement id or updated_at, tracks where it left off. An entity column such as tenant_id becomes the key through a primary label.

The result is two kinds of evidence in one timeline:

• Sentry issue alerts: what failed and when.
• Postgres rows: the orders, tenants or accounts around that moment.

If the second signal comes from an API instead of a table, the HTTP API (poll) connector polls a JSON endpoint on a schedule and stores one event per item. It fits the same purpose.

This is the evidence an AI SRE works from. See AI SRE for how the pieces fit together.

Set it up

1. Create the Sentry webhook source in Tares. Add a webhook source with the signing options for Sentry. action is a top-level field in the Sentry payload, so it works as the event_type_field. Replace the placeholder with your own Client Secret in step 2.

   - name: sentry-issues
     connector: webhook
     config:
       event_type_field: action
       signature_scheme: hmac_sha256
       signature_header: Sentry-Hook-Signature
       signing_secret: <client-secret>

   Then declare a label for each payload field you want to correlate on and mark one primary, choosing the field that identifies the entity you care about. Copy the ingest endpoint from the source page. The signing options are described in the 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 alert rules can use it. Copy the integration Client Secret into the Tares source as signing_secret.

3. Add the Postgres table. In the console go to Sources, Add source, Postgres. Enter the connection URL and press Discover. Tares lists the tables it can see and proposes the cursor, entity key and labels from the columns. You can also ask a connected agent to ingest the table. Or create the source from YAML:

   - name: orders
     connector: postgres
     poll: 10s
     config:
       dsn: postgresql://user:pass@host:5432/appdb
       table: orders
       cursor_column: updated_at
       columns: id,tenant_id,status,amount,updated_at   # empty = every column
       labels:
         - { name: tenant_id, field: tenant_id, primary: true }
         - { name: status, field: status }

   Pull only the columns that help during an incident. The dsn is stored as a secret and is redacted in the API. The Postgres server must be reachable from the Tares host, and the driver ships with Tares.

4. Verify both sources. Open each source. Recent events shows what arrived, and Fields shows which fields come in and how often. Use Fields on the Postgres source to confirm the key column is always present. Trigger a test alert from Sentry to see its event arrive.

What you get

• Sentry issue alerts and your own application rows on one timeline, so an alert comes with the data around it.
• Rows that show who or what the incident touched, such as the tenant, the order status or the amount, alongside the alert.
• A source of truth that stays current. The cursor column picks up new and changed rows on each poll, every 10 seconds in the example.
• Signed Sentry deliveries, with the signature as the authentication.
• A lossless payload for every Sentry event, so labels you declare later can still reach every field.
• A choice of columns, so you decide how much of the table enters Tares.

When something else fits

• If the second signal is an API response rather than a table, use the HTTP API (poll) connector. It stores one event per item and takes one credential header.
• If your cursor column does not grow, such as a table with no id or updated_at, the Postgres connector cannot track new rows, so poll an API that exposes the data instead.
• If you only need a quick look at the Sentry alerts themselves, the webhook source alone is enough.

Related