Alerting
Configure notification channels and alert rules for issue lifecycle, spikes, downtime, recovery, SSL expiry, and missed heartbeats.
Channels
Channels are notification destinations. ErrTap supports:
- Email — one or more addresses
- Slack — incoming webhook URL
- Discord — channel webhook URL
- Microsoft Teams — a Workflows "When a Teams webhook request is received" URL (legacy connector URLs work too); alerts arrive as Adaptive Cards
- Google Chat — space webhook URL
- ntfy — a topic URL such as
https://ntfy.sh/my-team-alerts(self-hosted servers work, including under a sub-path) plus an optional access token for protected topics. Downtime and missed crons are sent at urgent priority so they break through Do Not Disturb. - PagerDuty — an Events API v2 integration key.
DOWNTIMEopens a PagerDuty incident and aRECOVERYrule routed to the same channel resolves it automatically. - Generic webhook — any HTTP endpoint that accepts the alert JSON payload
Every channel except Email requires the Pro plan. Channel secrets are encrypted at rest. Use Test on any channel to verify delivery before wiring it to rules.
Alert types
| Type | When it fires |
|---|---|
NEW_ISSUE | A never-before-seen error group appears |
REGRESSED_ISSUE | A resolved issue reopens as a regression (how that's decided), or a snoozed issue gets an event after its snooze ends |
ISSUE_FREQUENCY | One issue receives at least N events within T minutes (1–60) |
DOWNTIME | An uptime check is confirmed down |
RECOVERY | An uptime check recovers after a downtime incident |
SSL_EXPIRY | A monitored certificate crosses an expiry warning threshold |
CRON_MISSED | A heartbeat did not arrive within the grace window |
ERROR_SPIKE | Project event volume exceeds its recent baseline |
Rules
Rules bind an alert type to one or more channels. Each rule can be scoped to:
- A specific environment for
NEW_ISSUEandREGRESSED_ISSUErules - A minimum level for issue rules (
NEW_ISSUE,REGRESSED_ISSUE,ISSUE_FREQUENCY) — e.g. Fatal only to page on crashes but not on warnings. Levels rankdebug < info < warning < error < fatal;warnandcriticalfrom SDKs count aswarningandfatal.
Frequency rules
ISSUE_FREQUENCY rules catch an issue that is suddenly happening a lot, even though it isn't new — for example 100 events in 5 minutes. Each rule alerts once per crossing and re-arms after a full window has passed, so a sustained storm doesn't re-page every event. Unlike ERROR_SPIKE (whole-project volume versus its baseline), this watches individual issues against a fixed threshold. New or edited frequency rules take up to 30 seconds to apply.
Deduplication / cooldown
Rules carry a cooldown window: ErrTap fires at most one alert per issue (or check) per window. This means an error storm pages you once — not hundreds of times.
Configure the cooldown duration per rule in Alerts → Alert rules.
Configuring rules
Navigate to Alerts → Alert rules → New rule:
- Choose an alert type
- Select one or more channels
- Optionally select an environment for an issue lifecycle rule
- Set a cooldown window (default: 5 minutes)
- Save and test