Monitor and rotate Turnstile

Turnstile does not stay healthy on its own. Widgets multiply, keys get copied between environments, and a refactor can quietly delete the server-side check. The form keeps working, so nobody notices.

Read the analytics with one question in mind

Turnstile analytics in the Cloudflare dashboard distinguishes issued challenges and server validation results. Compare the two numbers.

A site with widget solves but no Siteverify calls is not protected. Tokens are being issued in browsers and nothing ever validates them. That is the silent failure mode: someone broke or removed the server check, and users see no difference.

Monitor a small set of signals: Siteverify success, invalid, timeout-or-duplicate, server errors, conversion, and support complaints. A spike in invalid-input-response right after a deploy usually means the frontend stopped sending the token field.

Make your own side observable too. Log every validation outcome:

console.log(JSON.stringify({
  event: 'siteverify',
  success: outcome.success,
  codes: outcome['error-codes'],
}))

Then watch it live while you exercise the form:

npx wrangler tail --format pretty

If submissions flow but no siteverify lines appear, you found the gap before an attacker did.

Keep an inventory

Keep an inventory of widget locations and environments: which pages render which site key, and which services hold which secret. You cannot rotate a key safely when you do not know who uses it.

Rotate without an outage

Rotate a secret by updating the server safely and verifying traffic before removing the old path. The dashboard and API expose a rotation control for the secret key, and the API variant can keep the previous secret valid for a short overlap window.

Order matters: generate the new secret, deploy it, confirm Siteverify succeeds with it, then invalidate the old one. Rotating first and deploying second takes the form down for every visitor.

Now build the routine. Create a dashboard checklist covering solves, validations, and error codes, and alert on a sudden drop in Siteverify requests for an active form. That one alert catches the failure that matters most: a form that stopped checking.