No hardcoded green badge
Status and reliability
There is no automated monitoring behind this page yet, so it does not pretend there is. Here is what runs on what, what can fail independently, and how to check for yourself.
A status page whose badge is written into the template is worse than none — it stays green through an outage. When real monitoring is wired up, this page will report it and will say so. Until then, the checks below are the accurate ones.
How to check right now
- Open a link. If an unlock page loads, Workers and D1 are answering. That is the check that matters to your visitors.
- Check Cloudflare. Everything here runs on their network:cloudflarestatus.com. An incident affecting Workers, D1 or R2 affects this site directly.
- Try creating a link. That exercises the full write path including Turnstile — the most dependency-heavy thing the product does.
What runs on what
Listed so you can reason about a partial failure. These fail independently — analytics being unavailable does not stop anyone unlocking a link.
- Marketing pages
- Static files on Workers Static Assets. Served from the edge with no compute — these stay up as long as Cloudflare does.
- Unlock pages
- Rendered on demand by a Worker with one D1 read. Dependent on Workers and D1 in the visitor's region.
- Link creation
- Worker + D1 write + Turnstile verification. The most dependency-heavy path in the product.
- Management
- Worker + D1. Independent of Turnstile.
- Analytics
- Writes go to Analytics Engine and never block a request. Reads use the account SQL API and degrade to an honest "unavailable" rather than to zeroes.
- Creator artwork
- R2, served through a Worker route with immutable caching.
What we design for
Analytics never block a request. Events are written fire-and-forget. If Analytics Engine is unavailable, visitors are entirely unaffected and the creator dashboard says so rather than showing zeroes.
Rate limiting fails open. If the limiter errors, requests proceed rather than the endpoint going down with it. The durable KV quota is still enforcing in the background.
Turnstile fails closed. The one place we fail the other way. That gate exists precisely for the moments when we are under pressure, and "the check errored so let everyone through" is how a spam wave becomes a spam flood.
Expiry does not depend on the cron. Expiry is evaluated from the timestamp on every request. The daily sweep is housekeeping — if it does not run for a week, expired links still stop the moment they lapse.
No SLA is offered. Practical consequence:keep your own copy of anything you gate, and do not make a Keyway link the only route to something important.
Reporting a problem
Something broken: support@subtounlock.app, with the slug and roughly when it happened. Every response carries anx-request-id header and error pages show the same value — including it makes a report actionable in one step instead of five.
A security issue: security@subtounlock.app, and see security.txt. Please do not test availability.