Get alerted when page speed drops

Turning on monitor_page_speed provisions a paired page-speed check that runs Google PageSpeed Insights against your URL every 6 hours. Beyond charting the scores, it alerts when the Lighthouse performance score crosses a threshold, and again when it crosses back.

Turn it on

Set monitor_page_speed on the HTTP check, either through Monitor Page Speed in the Optional checks section of the monitor form, or through the API, with an API key exported as SITEQWALITY_API_KEY and $JOB_ID set to the check’s id:

curl -X PUT https://api.siteqwality.com/http/job/$JOB_ID \
  -H "Authorization: Bearer $SITEQWALITY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "monitor_page_speed": true }'

A Page Speed Insights tab appears on the monitor once the first result lands. Read the latest result with GET /http/job/{job_id}/page_speed and the series with GET /http/job/{job_id}/page_speed/history.

What triggers an alert

Alerting is transition-only. Each run compares the previous run’s performance score against the current one:

Previous score	Current score	Result
at or above threshold	below threshold	Degraded alert fires
below threshold	at or above threshold	Recovered alert fires
both below		nothing
both at or above		nothing

A score sitting exactly at the threshold counts as healthy. The comparison is strictly “below”.
A monitor that stays degraded does not re-alert every 6 hours. You get one alert on the way down and one on the way back up.

The very first page-speed run has no previous score to compare against, so it never alerts however bad the score is.

The threshold

performance_threshold is 0.5 on every monitor. GET /http/job/{job_id}/page_speed returns it, but no endpoint or dashboard field changes it. So you are alerted when the Lighthouse performance score drops below 50 out of 100, and again when it climbs back to 50 or above.

The value is on Lighthouse’s native 0.0 to 1.0 scale. Alert text converts it for display, so 0.5 shows as 50/100.

Only the performance category is compared. SEO, accessibility, and best-practices scores are collected and charted, but nothing alerts on them.

Where the alert goes

Page-speed alerts fan out through the parent HTTP monitor’s notification groups, over email, SMS, Slack, webhook, Telegram, Discord, and Microsoft Teams only.

PagerDuty, Jira Service Management (Opsgenie), Google Chat, Mattermost, Pushover, and Pushbullet channels are skipped (see which alerts reach which channels). If a monitor’s group contains only those types, its page-speed alerts go nowhere: add an email or Slack channel to the group if you want page-speed coverage.

What it does not do

A page-speed crossing is a notification and nothing more. It does not:

open an incident, so it never pages an on-call rotation or triggers an escalation policy;
record a state transition, so it never affects uptime percentage or SLA reports;
appear on a status page;
change the HTTP monitor’s own status.

Maintenance windows

Page-speed alerts are covered by the same maintenance windows as the parent monitor, matched on the HTTP check’s tags.

Inside a window, a degraded alert is held until the window ends and then released. If the score recovers before the window ends, the held alert is dropped and no recovery alert is sent either.

Practical notes

The 6 hour schedule is not configurable, so a regression can be up to 6 hours old before you hear about it.
Rate limits and transient 5xx responses from Google’s PageSpeed Insights API are retried on the next scheduled run rather than surfacing as a failure.
Google gets 2 minutes per run. If PageSpeed Insights has not returned a result by then, or Lighthouse cannot load the page, the run is skipped: the last scores stay in place, nothing alerts, and the next run tries again.
There is no mobile or desktop toggle: Site Qwality sends no strategy parameter, so the analysis runs with Google’s own default.