Kontiny

Service status

Green here means checked, not quiet. Every one of these counts carries a timestamp, and a passing result older than three cadences is counted as degraded rather than as a pass. “Never checked” is a state of its own: it means no result has ever been recorded, which is not the same as nothing being wrong.

Some things cannot be checked from in here, and those are counted separately. Whether this site is serving is one of them: a request the service makes to its own public address is answered by the edge rather than by the service, so a monitor running inside it would be reporting on the wrong thing. Those checks are probed from outside at deploy time and are counted as neither passing nor failing here — an unanswerable question gets its own row rather than a colour. An outside probe that could not get an answer counts the same way.

A feature that is switched off by design is not a fault. Its checks are left out of the counts and the colour above, and the number of them is shown on its own row, so the total never shrinks without saying so. Switch the feature on and its checks are counted again.

This page reports counts and an overall state, not which check is which. That is deliberate: naming a degraded subsystem to an unauthenticated visitor is a map for anyone who wants to use it, and a list with one name withheld would point straight at the withheld one. The named list is on the operator dashboard.

Nothing on this page is derived from any user's activity. Sync times, notification history and analysis usage are all operator-only, because with a user base this small they would describe one person's day rather than the health of a service.

This page is served ahead of the OAuth provider and the MCP handler and shares no code with either, so it keeps answering when they do not. If it is reachable and the last self-check is recent, the monitor is alive; if the last self-check is old, take this page's other numbers as history rather than as news.