What alerts are
Alerts indicate that something unusual was detected during a scheduled scan. They appear in the alerts overview and can optionally be forwarded by email or webhook.
Warning and critical
Alerts are classified by severity:
- Warning stands for something unusual that should be watched or prioritised
- Critical stands for a clearer need to act, for example a failed scan or clearly critical thresholds
This distinction affects both the UI and the sending of emails and webhooks.
Alert modes
How an alert is triggered depends on the mode chosen for the scan target.
Auto mode
turbometrics detects anomalies automatically — without you having to define target values:
| Alert type | Condition | Severity |
|---|---|---|
| Score drop | Score falls by ≥ 10 points vs. the last scan | Warning |
| Score drop | Score falls by ≥ 20 points vs. the last scan | Critical |
| TTFB | TTFB more than doubled vs. the last scan | Warning |
| TTFB | TTFB exceeds 3 sec. | Critical |
| TBT | TBT exceeds 600 ms | Warning |
| TBT | TBT exceeds 1,200 ms | Critical |
| HTTP status | Page does not respond with HTTP 200 | Critical |
| Visual regression | Screenshot deviates by ≥ 15% from the last healthy capture | Warning |
| Visual regression | Screenshot deviates by ≥ 30% from the last healthy capture | Critical |
| Scan failure | Scheduled scan fails | Critical |
Score drop and TTFB doubling need a previous scan as a basis for comparison. On the first scan of a target, only the absolute TTFB limit applies.
Visual regression detection is optional and has to be enabled per scan target (see below). Desktop and mobile are assessed separately and trigger independent alerts.
Custom mode
You define absolute thresholds for each metric yourself — one for warning and one for critical:
- Score: alert when the score falls below the configured value
- TTFB: alert when TTFB exceeds the configured value
- LCP: alert when LCP exceeds the configured value
- TBT: alert when TBT exceeds the configured value
- Visual regression: alert when the pixel deviation from the last healthy capture exceeds the configured percentage — configurable separately for desktop and mobile
Leaving a field empty means: this threshold is disabled. Scan-failure alerts can additionally be enabled in custom mode.
Visual regression detection
On every scan, turbometrics compares the current screenshot with the last capture in which no visual anomaly was present ("baseline"). If the screenshot deviates too far from it, an alert is triggered — for example when a deployment has broken the CSS or a plugin update has changed the layout.
- The check is disabled by default and has to be enabled per scan target.
- Desktop and mobile are assessed and evaluated independently of each other.
- As long as a visual alert is open, the baseline stays frozen — only a scan without anomalies sets a new reference.
- In auto mode the default values of 15% (warning) and 30% (critical) apply; in custom mode both values can be set freely per target.
Which alert types exist
| Type | Description |
|---|---|
score_drop |
Score dropped sharply (auto mode) |
score_below_threshold |
Score below the threshold (custom) |
ttfb_above_threshold |
TTFB above the threshold or sharply increased |
lcp_above_threshold |
LCP above the threshold (custom) |
tbt_above_threshold |
TBT above the threshold (custom) |
http_status |
HTTP status not 200 (auto mode) |
visual_regression_desktop |
Visual deviation on the desktop view |
visual_regression_mobile |
Visual deviation on the mobile view |
scan_failed |
Scheduled scan failed |
States in the interface
Alerts go through several states:
- unread — new, not yet opened in the UI
- read — acknowledged
- hidden — deliberately removed from the list; sending of emails is suppressed as well
- resolved — the problem has cleared up
When an alert reaches the resolved state, turbometrics automatically sends a recovery notification — by email and webhook, provided that is enabled for the target in question. That way you know not only when a problem occurred, but also when it was resolved.
Filtering and managing alerts
The alerts overview at /alerts is built like an inbox.
Choose a view:
- New (default) — unread, open alerts
- All — all alerts that are not hidden, open and resolved
- Resolved — only alerts that have already been resolved
- Hidden — manually hidden alerts
Further filters:
- priority: Warnings only or Critical only
- type: e.g. score, TTFB, LCP
- source: Scans or Real user data
- free-text search by title, domain or URL
All filters can be combined and are kept while paging.
Actions:
- Mark all as read — appears in the "New" view when there are unread alerts
- Hide all read — appears in the "All" view when there are read alerts
- individual alerts can be marked as read via the checkmark or hidden via the ✕
Alert delay: only after X consecutive bad scans
Short-term outliers — for example a single scan with elevated TTFB — should not lead to a notification straight away. That is what the "Alert after X consecutive bad scans" setting per scan target is for.
How it works:
- If a measured value is above the threshold, an internal counter for this alert type is incremented.
- Only when the counter reaches the configured value is the alert actually opened and a notification triggered.
- If the page recovers in between, the counter is reset.
- If an alert is already open, it stays open — the counter no longer plays a role then.
Default value: 2 — an alert only opens when the same problem occurs twice in a row.
A value of 1 means: an immediate alert on the first occurrence. Values up to 3 can be set. The setting applies equally to all alert types of the scan target — scan-failure alerts follow this rule as well.
Problem cycles
An alert is more than a one-off message. If a problem clears up and comes back later, a new problem cycle becomes visible — as a separate alert. This helps especially with unstable sites or recurring load problems.
A hidden alert is only created anew once the problem cycle has been completed in full: problem → recovery → new problem.
Using alerts sensibly day to day
What has proven itself:
- set up the critical targets first
- set realistic thresholds
- only enable warnings where early signals are genuinely useful
- use hiding instead of ignoring — hidden alerts produce no further emails
That way alerts stay valuable instead of noisy.
Live-data alerts
Besides scan-based alerts, there are also alerts for live data (real user monitoring). These are not based on individual lab scans, but on the p75 value of real visitor measurements. Configuration and behaviour are documented separately.
Difference to notifications
Alerts are not the same as notifications:
- Alerts show problem states
- Notifications show what was sent by email or webhook
For the sending history there is a separate area, the alert history.