Sentry

OpenSRE queries Sentry to retrieve recent issues, error events, and stack traces — correlating application errors with infrastructure alerts to identify root causes faster.

Prerequisites

Sentry account with at least one organization
Auth token with event:read scope (Issues lookup)
For uptime watching: also alerts:read (or org:read) so opensre sentry uptime can list monitors

Setup

Option 1: Interactive CLI

opensre integrations setup

Select Sentry when prompted and provide your organization slug and auth token.

Option 2: Environment variables

Add to your .env:

SENTRY_ORG_SLUG=your-organization-slug
SENTRY_AUTH_TOKEN=sntrys_your_token
SENTRY_URL=https://sentry.io           # optional, for self-hosted Sentry
SENTRY_PROJECT_SLUG=my-project         # optional, to scope to one project
SENTRY_STATS_PERIOD=24h                # optional, issue search time window

Variable	Default	Description
`SENTRY_ORG_SLUG`	—	Required. Your Sentry organization slug
`SENTRY_AUTH_TOKEN`	—	Required. Sentry auth token with `event:read` (add `alerts:read` for uptime watch)
`SENTRY_URL`	`https://sentry.io`	Override for self-hosted Sentry
`SENTRY_PROJECT_SLUG`	—	Scope queries to a specific project
`SENTRY_STATS_PERIOD`	`24h`	Time window for issue searches (e.g. `24h`, `14d`, `90d`)

A search returns up to 100 issues per query (Sentry’s maximum page size) within the SENTRY_STATS_PERIOD window. Widen the window (e.g. SENTRY_STATS_PERIOD=14d) to surface older issues. If you expect more issues than appear, the cause is almost always the time window or a SENTRY_PROJECT_SLUG scope — not a cap of one.

Option 3: Persistent store

{
  "version": 1,
  "integrations": [
    {
      "id": "sentry-prod",
      "service": "sentry",
      "status": "active",
      "credentials": {
        "base_url": "https://sentry.io",
        "organization_slug": "your-org",
        "auth_token": "sntrys_your_token",
        "project_slug": "my-project"
      }
    }
  ]
}

Creating an auth token

Recommended: Organization Token

In Sentry, go to Settings → Developer Settings → Organization Tokens
Click Create New Token
Enable the event:read scope (and alerts:read if you use uptime watch)
Copy the token

Alternative: Internal Integration For broader access, create an Internal Integration under Settings → Developer Settings → Internal Integrations.

The organization slug appears in your Sentry URL: https://sentry.io/organizations/<slug>/

Verify

opensre integrations verify sentry

Expected output:

Service: sentry
Status: passed
Detail: Sentry validated for org your-org; 30 issue(s) in the last 7 days

Morning digest (scheduled)

Deliver a daily unresolved-issues summary to Slack, Telegram, or Rocket.Chat. This uses the headless sentry-summary skill path (tools + LLM answer via the gateway), not the investigation pipeline or generic opensre cron kinds. When an uptime watch schedule is running, the skill also calls get_sentry_uptime_digest to include downtime/recovery context in the digest.

Command	What it does
`/sentry digest schedule add …`	Same as CLI — schedule from the REPL
`opensre sentry digest run`	Run once and print the digest to stdout
`opensre sentry digest schedule add`	Schedule daily delivery (cron + provider + chat)
`opensre sentry digest schedule list`	List Sentry digest schedules
`opensre sentry digest schedule run TASK_ID`	Run a scheduled digest immediately
`opensre sentry digest schedule remove TASK_ID`	Remove a schedule

Example — weekdays at 08:00 London time to Telegram:

opensre sentry digest schedule add \
  --cron "0 8 * * 1-5" \
  --tz Europe/London \
  --provider telegram \
  --chat-id "-1001234567890"

Example — same schedule to a Slack channel (C… member/channel id):

opensre sentry digest schedule add \
  --cron "0 8 * * 1-5" \
  --tz Europe/London \
  --provider slack \
  --chat-id C0123ABCD

Example — same schedule to a Rocket.Chat channel (requires token credentials — see Rocket.Chat, an incoming webhook alone cannot target an explicit --chat-id):

opensre sentry digest schedule add \
  --cron "0 8 * * 1-5" \
  --tz Europe/London \
  --provider rocketchat \
  --chat-id "#alerts"

Optional --project my-service scopes the digest to one Sentry project. When an uptime watch schedule is running, the sentry-summary skill automatically includes an Uptime / downtime (last 24h) section with monitors that are still down or recovered in the window. If no uptime watch history exists, the digest stays Issues-only. The gateway daemon picks up scheduled digests automatically when it is running. If the LLM is unavailable, the run fails with an error.

The count reflects issues seen in the last 7 days (capped at 100, shown as 100+ when it saturates). Use a search (e.g. search_sentry_issues during an investigation) to enumerate the full issue set over a custom window.

Uptime watch (downtime notifications)

Poll Sentry uptime monitors (Alerts / Uptime — not the Issues digest) and ping Slack, Telegram, or Rocket.Chat only when a monitor transitions to down or recovered. Quiet polls deliver nothing. This is separate from the morning Issues digest (sentry-summary / Feature #10).

Command	What it does
`opensre sentry uptime check`	List current uptime monitor health once
`opensre sentry uptime watch add`	Schedule polling (default every 5 minutes)
`opensre sentry uptime watch list`	List uptime watch schedules
`opensre sentry uptime watch run TASK_ID`	Run a watch tick now (may notify)
`opensre sentry uptime watch remove TASK_ID`	Remove a watch schedule

Example — poll every 5 minutes and ping Slack on transitions:

opensre sentry uptime watch add \
  --cron "*/5 * * * *" \
  --tz UTC \
  --provider slack \
  --chat-id C0123ABCD

Requires alerts:read (or equivalent) on the Sentry token. The agent tool list_sentry_uptime_alerts exposes the same monitor list in chat/investigation. Schedule an uptime watch alongside the morning digest so the sentry-summary skill can include yesterday’s downtime summary via get_sentry_uptime_digest; the watch records DOWN/RECOVERED transitions locally for that rollup. Follow-ups (not in v1): inbound Sentry webhooks and auto-remediation attempts.

Telemetry knobs

Variable	Default	Description
`OPENSRE_SENTRY_DSN`	—	Override the bundled Sentry DSN
`OPENSRE_SENTRY_DISABLED`	`0`	Set to `1` to disable Sentry entirely
`OPENSRE_SENTRY_LOGGING_DISABLED`	`0`	Set to `1` to disable automatic forwarding of `logger.error` and `logger.exception` calls to Sentry as events, without affecting `capture_exception`

Verify Error Reporting

Send one test event to confirm OpenSRE can report runtime errors:

opensre debug sentry

For a custom or self-hosted project, set the DSN first:

OPENSRE_SENTRY_DSN=https://public-key@example.ingest.sentry.io/123 opensre debug sentry

Sentry DSN host: example.ingest.sentry.io
Sentry event ID: <event-id>
Sentry flush sent: yes

The event is synthetic and tagged debug=true. If telemetry is disabled, the command exits non-zero without sending anything.

Troubleshooting

Symptom	Fix
403 Forbidden	Ensure the token has `event:read`; for uptime watch also `alerts:read`
Organization not found	Verify `SENTRY_ORG_SLUG` matches the slug in your Sentry URL
Connection refused	Check `SENTRY_URL` for self-hosted instances
No issues returned	Normal if no issues exist in the time window — check `SENTRY_PROJECT_SLUG`
Fewer issues than the Sentry UI shows	Widen `SENTRY_STATS_PERIOD` (e.g. `14d`) and confirm the search isn’t scoped to the wrong `SENTRY_PROJECT_SLUG`

Security best practices

Use an Organization Token with only event:read — do not use admin tokens.
Store the token in .env, not in source code.
Rotate tokens periodically.

Overview

LLM providers

Observability and incidents

Cloud, code, and collaboration

Messaging

Data and workflow systems

Prerequisites

Setup

Option 1: Interactive CLI

Option 2: Environment variables

Option 3: Persistent store

Creating an auth token

Verify

Morning digest (scheduled)

Uptime watch (downtime notifications)

Telemetry knobs

Verify Error Reporting

Troubleshooting

Security best practices

​Prerequisites

​Setup

​Option 1: Interactive CLI

​Option 2: Environment variables

​Option 3: Persistent store

​Creating an auth token

​Verify

​Morning digest (scheduled)

​Uptime watch (downtime notifications)

​Telemetry knobs

​Verify Error Reporting

​Troubleshooting

​Security best practices

Prerequisites

Setup

Option 1: Interactive CLI

Option 2: Environment variables

Option 3: Persistent store

Creating an auth token

Verify

Morning digest (scheduled)

Uptime watch (downtime notifications)

Telemetry knobs

Verify Error Reporting

Troubleshooting

Security best practices