Guides
Configure alerts
Monitoring is only useful if it tells you the right things at the right time. Alerts are the bridge between a rescan and your inbox — tune them so they stay signal, not noise.
Alert types
| Type | When it fires |
|---|---|
| new_finding | A risk indicator appeared that wasn't in the baseline — e.g. a marketing change added a pixel to an appointment page. The signal most teams care about most. |
| resolved_finding | A previously open finding is gone on the latest rescan. Useful as confirmation; many teams keep this one quiet to reduce volume. |
| score_drop | The overall score fell by a meaningful margin between scans, a good catch-all for 'something got worse'. |
| cert_expiring | The TLS certificate is approaching expiry. Renew before it lapses to avoid an outage and a transport-security finding. |
A sensible starting configuration
For most practices: enable new_finding, score_drop, and cert_expiring; leave resolved_finding off until you want the positive confirmations. Channels are email today (delivered via the platform’s transactional email provider). Set per-site overrides if one client wants everything and another wants only critical changes.
Pair alerts with CI for the fastest loop
Alerts catch changes after they ship. If you run a telehealth or marketing site with a deploy pipeline, also wire a scan into CI so a new tracker fails the build before it reaches patients — see the telehealth CI recipe.