Monitoring that tells you when your site regresses - and how
A one-time audit is a snapshot; sites drift. Here is how our monitoring re-scans your pages on a schedule, what counts as a regression, and every channel the alert reaches you on - including signed webhooks to your own systems.
Artykuły są napisane po angielsku.
Accessibility and site health are not one-time achievements. A CMS update swaps a template, a marketing tweak changes a button colour, a deploy drops a label - and the site that passed its audit in March quietly fails in June. Nobody re-checks manually, so the drift goes unnoticed until a complaint (or a regulator) finds it first.
How the monitoring loop works
You register the pages that matter and pick a cadence. Each site gets a baseline score from its first scan; after that we re-scan on schedule and compare. A meaningful score drop, a spike in critical issues, or the site becoming unreachable counts as a regression - normal jitter does not, so you are not paged over noise.
Where the alert reaches you
A regression fans out to every channel your organization has connected: an in-app notification, email to your team, your Slack channel or Discord, browser push - and, for teams with their own tooling, a signed webhook. That last one matters if you automate: OAKMONT POSTs a JSON event (monitor.regression, with the score, the previous score and the critical-issue count) to your endpoint, signed HMAC-SHA256 so your receiver can verify it came from us and reject replays. Your ticketing system can open the ticket before a human reads the email.
The badge is the same data
Monitored sites can embed a live status badge showing the current score. It is not decoration - it renders from the latest scan, so it goes stale the moment your site does. That is the point: a claim you can verify beats a promise on a landing page.
Monitoring starts free for one site - add yours from the scanner or your portal.