Alerts & Notifications
Stay informed when issues occur. FlareWarden supports email notifications and webhooks to integrate with your existing tools.
Email Notifications
Receive alerts directly in your inbox. Each team member can configure which notifications they receive.
Learn more →Webhooks
Send HMAC-signed JSON to any HTTPS endpoint you run, or to a tool that accepts an incoming JSON webhook and lets you map its fields.
View documentation →Slack, Discord, Google Chat & Microsoft Teams
Native destinations — formatted alert messages in your channel or space (Teams gets an Adaptive Card), with the monitor, the cause, and a link straight to it. No JSON, no code.
Email Notifications
Configure which alerts each team member receives
Email notifications are enabled by default for all team members. Each person can customize which types of alerts they receive.
Available Email Alerts
| Alert Type | Description | Default |
|---|---|---|
| Incident Started | When a monitor goes DOWN or DEGRADED | On |
| Incident Recovery | When a monitor returns to UP status | On |
| SSL Expiry | When certificates are expiring soon | On |
| SSL Changes | When certificates are renewed or changed | Off |
| Certificate Changes | When certificate details change | Off |
| Issuer Changes | When certificate authority changes | Off |
| DNS Changes | When DNS records change | Off |
Configure your preferences in Settings → Notification Preferences
How Alerts Work
Understanding the alert flow from detection to notification
Check Runs
FlareWarden checks your monitor at the configured interval
Issue Detected
If a check fails, other regions re-check it; if any of them sees it healthy, no alert is sent
Incident Created
If the failure is confirmed, an incident is created
Notifications Sent
Emails and webhooks are triggered based on each user's preferences
Recovery
When the issue resolves, recovery notifications are sent
Reducing False Alarms
Cross-region validation prevents unnecessary alerts
FlareWarden uses cross-region validation to prevent false alarms from temporary network issues:
- When a site's uptime check fails, other regions are asked to re-check it before any alert is sent. Content and DNS checks, and dependency checks that load a URL, are re-checked the same way; a dependency that follows its provider's status page alerts on what that page reports
- If any re-check gets a healthy response, the failure is treated as a false alarm and no alert is sent
- A failure is confirmed if no re-check succeeds and at least one region confirms it. A region that has not answered within two minutes counts as confirming, unless another region's regular check has seen the site up in that time. A confirmed failure that lasts two minutes alerts you