Checking a site after every deployment

Unit and integration tests check the code. They do not check what the internet receives after the CDN, the proxy, the platform and the DNS have all had their say.

Many production-only failures live in that gap: security headers present locally and missing behind the edge, a `noindex` left from staging, mixed content introduced by an environment variable, a redirect rule that loops.

An external scan of the deployed URL sees exactly what a visitor and a crawler see, which is the thing the deployment was for.

It also produces a baseline for every release, so the comparison between two deployments is available without planning it.

The scan API accepts `POST /api/public/v1/scans` with a website identifier or a URL, and optionally a page limit and a deep-scan flag.

Requests authenticate with an API key sent as a Bearer token; a missing or invalid key is refused with a 401 and a readable error.

Plan limits — pages per scan, monthly quota, deep scans — are enforced on the server, so the API can never grant more than the dashboard.

`GET /api/public/v1/scans` lists recent scans with their status, page count, issue totals and overall score, and each scan can be fetched by its identifier.

Keep the key in the pipeline's secret store, never in the repository, since it can start scans against your quota.

Webhooks fire on `scan.started`, `scan.completed`, `scan.completed_with_warnings` and `scan.failed`, to endpoints you register and for the events you choose.

Each delivery is signed in an `X-VeriFixScan-Signature` header carrying a timestamp and an HMAC-SHA256 of the timestamp and body, so the receiver can reject forgeries and replays; the replay window is five minutes.

Deliveries are timeout-bounded, retried with backoff and journalled, and destinations on private or internal networks are refused.

A webhook failure never fails the scan, so a pipeline should treat a missing callback as "check the scan", not as "the site is broken".

Selected findings can be turned into GitHub issues from the report, one issue per finding, with the evidence attached.

Evidence is redacted before it is copied: keys that look like credentials, bearer tokens or API keys are dropped, long values truncated and deep structures cut off.

Slack notifications can carry the same run to a channel, grouped per scan rather than per issue.

Prioritising what to open issues for is its own decision; the findings list carries the severity and the reason, which is what a ticket needs.

A deployment gate built on the whole score will block releases for unrelated long-standing findings. Gate on change instead: new findings and regressions against the previous deployment.

Critical findings of a small set of kinds — a `noindex` on live pages, HTTPS failing, a redirect loop, secrets in served files — are reasonable hard stops.

Everything else is better as an issue than as a failed pipeline.

Scan duration depends on the site and the page limit, so asynchronous gating through the webhook is more robust than a pipeline step that waits.

Each delivery is a JSON body with a unique event id, the event name, a creation timestamp and the scan record, sent with a `VeriFixScan-Webhook/1` user agent.

A delivery that does not answer within ten seconds, or answers with an error, is retried up to three attempts in total, with the wait doubling between attempts.

Every attempt is journalled, so a missing callback can be traced to the endpoint's answer rather than guessed at.

Receivers should acknowledge quickly and do their work asynchronously, since a slow handler looks like a failure to a ten-second timeout.

The event id lets a receiver ignore a retried delivery it has already processed.