Blog
A Status Page Does Not Show CLI Failures
Uptime measures your API. It does not measure install, login, or a sample that exits on the developer's machine. Publish status for the service, and watch probes for the quickstart.
2026-09-17 · 6 min read · AethelLayer
Green means the health route returned 200
That is worth publishing. It is not adoption. A day can be fully green while every new evaluator fails device-code login or a missing environment variable.
Do not put quickstart failures on the public status page as an outage. They are not an outage. They are a product defect your users cannot see on that page either.
Incidents and evaluations are different queues
An incident is a region, an error budget, a start and an end. An evaluation failure is a command, a version, and a sentence. Mixing them trains on-call to ignore the inbox.
Page on the status incident. Review the probe clusters on a cadence. Both can be true in the same hour.
What to count beside uptime
Unique hashed developers per error code, time to first successful call, and how many probes became a reviewed draft. Those numbers move when the quickstart gets better. Uptime does not.
If probes are flat at zero, the probe is not installed on the first command. That is the bug to fix before you celebrate a quiet queue.
Tell evaluators the status URL in the timeout error
When the host is actually down, the CLI should link the status page. When the host is up and the CLI still fails, do not send them there. You will have taught them that the status page is useless.
The draft for a local failure should not be titled 'outage'. Title it with the error code.
Keep reading
Capture the failure before they leave
Capture the failure before they leave. Book early access or talk to sales, then install @aethellayer/sdk when you are onboarded.