Status
There is no dashboard here reporting on itself. This page asks the API the same question your CI would, from your browser, when you load it — so what it says is what you can actually reach, not what we would like to be true.
api.skiplink.dev
Checking… GET https://api.skiplink.dev/health
A single request from this browser, with a five-second limit. It reports
liveness — the process answered. Whether it can reach its database and
queue is /ready, which is deliberately not readable from here: its
failure text names which dependency is down, and that belongs to our load
balancer rather than to the internet.
If it is not answering
Your build does not silently pass. The CLI exits 3 — “could not complete” — which is a different exit code from 1, “this page has a new violation”. That distinction is deliberate: a pipeline should be free to retry one and block on the other, and a scan that could not run never reports as a pass.
If it stays down, tell us: hello@skiplink.dev. A reply from a person is the whole support model at this size, and we would rather hear it from you than find out later.
What we do not promise
No contractual uptime commitment, stated plainly in §10 of the terms rather than buried. We aim for high availability; we do not sell a number we cannot defend, and a service level agreement is a thing to earn rather than to write.
Why there is no history on this page
Because there is no monitoring behind it yet. A status page with a wall of green squares nobody is measuring is exactly the kind of claim this product exists to argue against — the same reason the coverage table is computed rather than asserted and a clean scan is not sold as compliance.
When there is external monitoring, its history goes here, including the outages. Until then this page does the one honest thing available to it: it checks, now, from where you are.