Keep getting error alerts when Sentry is down
Your error alerts only work while Sentry is up. To keep them during a Sentry outage, watch Sentry's own status page, send every error to a second Sentry-compatible DSN as well, and run a scheduled canary event whose alert pings a heartbeat. If ingestion or alerting breaks, the heartbeat stops and another tool tells you.
What can go wrong with Sentry alerting
- Ingestion stops. Sentry stops accepting or processing events in one region. Your SDKs keep running, but events are dropped or delayed, so no new issues and no alerts appear. Sentry's status page lists ingestion separately for its US and EU regions.
- Alerting stops while ingestion works. Events arrive and show in the dashboard, but alert rules do not fire, or notifications to Slack, email or PagerDuty are late. This is the quiet failure: nothing looks wrong until someone opens Sentry. Sentry's incident on 19 October 2026 said alerting was affected too.
- The dashboard is down. Alerts still arrive but you cannot open the issue to read the stack trace. Annoying, but your alerting still works.
- Your own setup drops events. Spike protection or rate limits kick in, the monthly quota runs out, a DSN is rotated in one service but not in another, or a deploy ships with the SDK turned off. Sentry is up, yet your errors never reach it.
- The network path breaks. A firewall rule, an outbound proxy or a DNS problem between your servers and the ingest endpoint stops events. SDKs send in the background and say nothing about it at the default log level.
The signals that matter, with alert thresholds
| Signal | Alert when | Why it matters |
|---|---|---|
| Sentry's status page | a component you use is not operational | Tells you when Sentry knows about a problem. It can lag behind the real start. |
| Canary event alert | no heartbeat ping within the canary interval plus grace | Proves the whole path works: SDK, ingestion, alert rule and notification. |
| Errors in the fallback destination | the fallback shows errors that Sentry does not | Reveals dropped events from quotas, rate limits or a regional outage. |
| Error lines in your application logs | error logs rise while Sentry shows nothing new | Logs are a second, independent record of the same errors. |
| SDK send results (debug mode) | send failures or HTTP 429 responses | 429 means rate limited or out of quota: events are being dropped. |
Thresholds are starting points. Tune them after a week of data: an alert nobody acts on should be raised or removed.
How to check Sentry alerting by hand
curl -s https://status.sentry.io/api/v2/summary.json | jq '.status, [.components[] | select(.status != "operational") | {name, status}]'
curl -s https://status.sentry.io/api/v2/incidents.json | jq -r '.incidents[:5][] | "\(.created_at) \(.impact) \(.name)"'
SENTRY_DSN="https://<key>@<host>/<project>" sentry-cli send-event -m "canary: error pipeline test"
python -c "import sentry_sdk; sentry_sdk.init(dsn='https://<key>@<host>/<project>', debug=True); sentry_sdk.capture_message('canary'); sentry_sdk.flush(5)"
The status URLs are the public Statuspage API of status.sentry.io; no account is needed. Replace the DSN parts with your own.
Send errors to a second, Sentry-compatible DSN
Sentry SDKs take one DSN, but they let you replace the transport, the part that sends events. A small transport can send each event to two DSNs: your normal Sentry project and a backup. Send to both all the time, not only on failure: you cannot detect an outage reliably from inside the SDK, and a backup that already has the last few days of errors is far more useful than an empty one.
import sentry_sdk
from sentry_sdk.transport import HttpTransport, Transport
PRIMARY_DSN = "https://<key>@o0.ingest.sentry.io/<project>"
BACKUP_DSN = "https://<key>@puzaricloud.in/<project>" # any Sentry-compatible DSN
class FanOutTransport(Transport):
"""Send every envelope to the primary DSN and to a backup DSN."""
def __init__(self, options):
super().__init__(options)
self.targets = [HttpTransport(options), HttpTransport({**options, "dsn": BACKUP_DSN})]
def capture_envelope(self, envelope):
for t in self.targets:
t.capture_envelope(envelope)
def flush(self, timeout, callback=None):
for t in self.targets:
t.flush(timeout, callback)
def kill(self):
for t in self.targets:
t.kill()
sentry_sdk.init(dsn=PRIMARY_DSN, transport=FanOutTransport)import * as Sentry from "@sentry/browser"; // same exports in @sentry/node
const PRIMARY_DSN = "https://<key>@o0.ingest.sentry.io/<project>";
const BACKUP_DSN = "https://<key>@puzaricloud.in/<project>";
Sentry.init({
dsn: PRIMARY_DSN,
// the matcher returns every DSN this event should go to
transport: Sentry.makeMultiplexedTransport(Sentry.makeFetchTransport, () => [
{ dsn: PRIMARY_DSN },
{ dsn: BACKUP_DSN },
]),
});The JavaScript helper has been in the SDK since version 7.50; check your version's docs for the exact matcher shape. Sending twice doubles your outbound events, so check the backup's daily limit and keep sample rates the same on both.
The backup can be anything that accepts the Sentry protocol: a self-hosted Sentry, GlitchTip, or Vigil's error tracking, which accepts events from unchanged Sentry SDKs at /api/<project>/envelope/ and alerts on new issues, regressions and spikes. Vigil keeps error events only: it accepts transactions, sessions and attachments but discards them, so it is a fallback for errors, not a full replacement for Sentry's performance features. The free plan includes one error project and 1,000 error events a day.
Prove alerting works with a canary and a heartbeat
Watching the status page tells you what Sentry has admitted. A canary tells you whether your own alerts would reach you right now. Every 15 minutes a cron job sends one known event. A Sentry alert rule matches it and calls a webhook, and that webhook is a heartbeat URL. As long as events are ingested and alert rules fire, the heartbeat gets a ping. If either part breaks, the pings stop and the heartbeat alerts you through a channel that does not depend on Sentry.
# every 15 minutes: send one known event through the normal pipeline */15 * * * * SENTRY_DSN="https://<key>@o0.ingest.sentry.io/<project>" sentry-cli send-event -m "canary: error pipeline test" # Sentry alert rule (set up once in Sentry): when the canary issue gets a new event, # send a webhook to the heartbeat URL below. Vigil accepts the POST as a ping. https://puzaricloud.in/ping/<token>
Set up the alert rule in Sentry so it fires each time the canary issue gets a new event, use the shortest action interval Sentry offers, and add a webhook action with the heartbeat URL. Trigger and integration names differ between Sentry versions and plans, so test it once: run the cron line by hand and check that the heartbeat shows a ping. Mark the canary issue so nobody resolves or ignores it, because that would change when the rule fires.
How to watch Sentry alerting with Vigil
- In New monitor choose Dependency and pick Sentry. Vigil reads status.sentry.io every few minutes: minor issues or maintenance send a notice, and a major or critical outage opens an incident.
- Create a Heartbeat named "Sentry canary" with a period of 15 minutes and a grace of 10 minutes. Use its ping URL, https://puzaricloud.in/ping/<token>, as the webhook in the Sentry canary alert rule described above.
- Send the heartbeat's alerts to a channel that does not go through Sentry: Telegram, Slack, Discord, email or a webhook from Vigil.
- Optional: create an error project under Errors and use its DSN as the backup in the fan-out transport, so you still see new errors while Sentry is down.
- Add an uptime or API check for your own app as well. It tells you when users are affected, whatever happens to error reporting.
Every alert goes to the channels you pick: email, Slack, Telegram, Discord, Microsoft Teams, Pushover, webhooks or on-call paging. Failures are confirmed by a second check before anyone is woken up.
Sentry alerting monitoring FAQ
Can a Sentry SDK send to two DSNs?
Not with a setting, but with a custom transport. The Python example above wraps two HTTP transports; the JavaScript SDK ships makeMultiplexedTransport, which sends each event to every DSN its matcher returns.
Does the backup DSN slow down my app?
No more than Sentry does today. SDKs send events from a background worker, so a second destination adds one more request per event, not a delay in your request path. If the backup is down, its sends fail on their own and the primary is not affected.
How do I know if Sentry is down right now?
Check Is Sentry down?, which reads Sentry's official status page every 5 minutes and keeps the history, or status.sentry.io itself. Remember that the status page shows what Sentry has acknowledged, which can lag behind the start of a problem.
Is Vigil a replacement for Sentry?
For error alerts, it can be: it accepts Sentry SDK events and groups them into issues. It does not keep performance transactions, session replays or profiles, so teams that use those keep Sentry and use Vigil as the fallback.