feat(sentry): watch Sentry uptime/downtime alerts and notify on domain outages

[larsspinetta12]

Problem statement

OpenSRE already has a Sentry Issues summary skill (sentry-summary — Features #3 / #10) that clusters and ranks unresolved error issue groups.

That skill does not cover Sentry Alerts / Uptime monitors. In a live dogfood session, critical downtime alerts were added for a domain that was taken down, but those did not appear in the Issues feed (tracer-30 issue search was empty for downtime-type issues). Expected agent behaviour was: pick up the downtime alerts, treat them as critical, and after recovery produce a report that no longer claims the domain is down.

Today, asking the agent about alerts / downtime against sentry-summary alone is a false expectation: Issues ≠ Alerts/Uptime.

What this is (product intent)

Proactive monitoring + notify, not an on-demand “is domain X up?” Q&A skill:

• Watch uptime / downtime alert state for domains (and related targets) already connected via Sentry.
• When something goes down / flips critical, ping the user (Slack / Telegram / configured notification channels — reuse existing delivery paths where possible).
• When it recovers, update / follow up so reports are not stale (“still critical” after the domain is healthy again).

This is adjacent to, but separate from, the Issues morning digest.

Proposed solution

1. New Sentry tooling for Alerts / Uptime (or wire Sentry MCP monitor/alert surfaces if sufficient) so OpenSRE can list active downtime alerts, severity, and affected target/domain.
2. Watch / notify path (scheduler, gateway listener, or Sentry webhook ingress — TBD) that:
   • polls or receives status for connected Sentry orgs/projects
   • on critical downtime: notify the configured channel
   • on recovery: send a clear recovery/update (accurate timeline: down → detected → recovered)
3. Agent surface: either a small dedicated skill (e.g. sentry-uptime / sentry-alerts) or investigation/chat tools only — do not fold this into sentry-summary (keep Issues clustering separate from outage watch).

Explicitly out of scope for this issue

• Expanding sentry-summary to “summarise all of Sentry”
• Multi-source Product Signal Summary (Feature Build context isolate #14 / Summarize Sentry, PostHog, GitHub, and Slack-reported product issues #3229 / Feature #14: Product Signal Summary across Sentry, PostHog, GitHub, Slack, and Discord (blocked by those skills being finished first) #3995)
• Full RCA / bringing the domain back up automatically

Acceptance criteria

• OpenSRE can see Sentry critical downtime / uptime alert state for connected orgs (not only Issues)
• When a watched domain/target goes down, the user is notified on a configured channel with severity = critical (or equivalent)
• When the domain recovers, a follow-up/report reflects healthy state (no stale “still critical”)
• sentry-summary remains Issues-only; docs clarify Issues digest vs uptime/alert watch
• E2E dogfood: domain down → notify critical → domain up → recovery update (manual staging OK)

Context / dogfood notes

• Triggered by Vaibhav’s downtime alerts dogfood (domain taken down + critical downtime alerts in Sentry).
• Related existing work: feat(sentry): add sentry-summary skill guidance #3970 / feat(sentry): add sentry-summary skill guidance #3971 (sentry-summary), feat(sentry): scheduled morning digest automation (Feature #10) #3979 (scheduled Issues digest / Feature Add tracer web app pipeline evidence and LLM hypotheses #10).
• Possible related surface: Sentry MCP monitors (docs/sentry-mcp.mdx) — evaluate before inventing a parallel API client.

AI usage disclosure

Issue drafted with AI assistance; product framing corrected by human (proactive watch + notify, not on-demand domain Q&A).