HTTP smart alerts: catch slowdowns before hard downtime
Beyond up/down pings, HTTP monitors can enable smart alerts: the scanner reviews recent scan rows, compares latency baselines, counts hard errors, and watches flapping—then opens a degraded incident and sends a separate email subject line when thresholds trip, with a cooldown between sends.
What the product actually evaluates
The implementation keeps the last twenty scans per monitor. It compares the median response time of the ten oldest successful checks against the ten newest, looks for repeated 5xx-class outcomes, and counts state changes between success and failure to approximate flapping—all before deciding the site is in a degraded performance state.
Why degraded incidents exist
Degraded incidents are a first-class incident type in the data model. They let you warn operators about slow or flaky behaviour without treating every blip as a full outage, while still feeding the same alert contacts pipeline you already use for down events.
Email throttling and wording
When smart logic fires, notifications reuse the same alert contact machinery as other incidents, but smart-alert emails use a dedicated degradation subject string from translations and only send again after a one-hour cooldown per monitor to avoid mailbox floods.
Who can turn smart alerts on
The shipped plan helper only allows creating monitors with smart alerts enabled for Enterprise paid workspaces (or superuser bypass in development). Starter and Team flows keep the toggle off so expectations match billing and support load.
How this differs from response-time charts
Response-time monitoring explains percentiles and trends for humans reading dashboards. Smart alerts automate a bounded ruleset on the same scan history to decide when to escalate to incidents and email—think signal vs. passive charting.
How this differs from SLA reports
SLA exports summarise uptime math over a chosen window. Smart alerts react scan-by-scan with a short rolling window so operators get an early warning before the SLA window closes.
Operational cautions
Because the logic depends on enough recent scans, brand-new monitors need time to populate history. Treat smart alerts as an extra layer on top of—not a replacement for—normal down alerts and on-call playbooks.
Where to configure it
On each HTTP monitor detail page, the smart alerts card appears when your workspace is eligible. Toggle it alongside your alert contact assignments so the right channel receives degradation mail.
What you can verify with SitePuls here
- Smart degradation evaluation runs from the HTTP monitor path where the UI exposes smart alerts; other monitor types use their own incident rules without this rolling-window heuristic.
- The helper inspects the latest twenty stored scans per monitor, comparing median latency of the oldest ten successful checks against the newest ten, counting hard-error scans, and counting success/failure transitions as a flapping signal.
- When thresholds trip, the code opens a degraded incident and can send `_notify_degraded` email with a translated degradation subject, applying a one-hour cooldown between smart-alert sends per monitor.
- Creating monitors with smart alerts enabled is gated to Enterprise paid workspaces (plus superuser bypass in development) in the shipped plan helper—Starter/Team flows keep the toggle off.
Where incident alerts can go
- Email addresses saved as alert contacts receive messages when incidents open or resolve (according to your notification settings).
- Telegram notifications via the SitePuls bot after you link a chat to an alert contact (including the bot /start flow for pending contacts).
- HTTPS webhooks that receive JSON with event type, monitor identifiers, status, timestamp, optional incident id, and a short message for generic integrations.
- Slack-compatible incoming-webhook formatting: alert contacts can use a dedicated mode so payloads match Slack-style incoming webhook expectations.
FAQ
Do smart alerts replace normal down notifications?
No. Hard failures still follow the standard incident path; smart alerts add a degraded branch with its own email copy and cooldown.
Can I use smart alerts on API or heartbeat monitors?
The shipped scanner hook runs only for HTTP monitors where the UI exposes the smart alert controls.
What latency numbers does the code compare?
It compares medians of successful checks in the oldest vs newest ten-scan buckets and flags degradation when recent median is at least 800 ms and 1.8× the baseline, or when other error/flapping thresholds hit.
How many errors trigger degradation?
Among the last twenty scans, three or more scans classified as hard errors contribute to a degraded decision, independent of the latency rule.
What counts as flapping?
More than three transitions between success-class and error-class outcomes inside the twenty-scan window is treated as flapping for this heuristic.
Can I disable smart alerts after enabling them?
Yes—toggle the checkbox on the monitor detail page; the next save persists `smart_alert_enabled` like any other monitor field.
Do public status pages show degraded state?
Public status pages summarise included monitors and incidents; degraded incidents follow the same incident tables you already expose—see the public status guide for layout specifics.
Where should I start reading?
Skim uptime monitoring for general incident flow, then response-time monitoring for percentile context, then return here for automated escalation rules.