Every state on this page comes from a check that ran, stored with the time it was taken. This is what that looks like — component by component, and ninety days deep.
THE COMPONENT BOARD
Six components, each with its own state.
Below is the board mid-incident: the analysis queue is falling behind while everything else keeps answering. That distinction is the point — a slow queue is not an outage, and the board says so.
Degraded performance
Everything is reachable, but one component is not behaving normally. Work is delayed rather than lost.
Checked 09:14:22 UTC
API
The backend that serves every authenticated request.
operational
Database
Customers, projects, incidents, analyses, and history.
operational
Queue store
Redis, backing the three background queues.
operational
Issue sync
Pulls issues from your error tracker every five minutes.
operational
Analysis
Redacts context, calls the model, and scores risk.
degraded
Notifications
Delivers email, Discord, and Telegram messages.
operational
Last 90 days of checksoldest → newest
Point at a day, or tab through them, to see what it recorded.
AND FOR THE PROJECTS YOU WATCH
The same reporting, pointed outward.
Uptime monitors check each registered project every minute and store the result with the time it was taken, so a project’s state is always traceable to a real observation.
Up
The last check reached the target and it answered healthily.
Down
The last check failed. This is the state that can raise a notification.
Unknown
No check has completed yet, so no claim is being made.
Paused
Checking is deliberately suspended.
REPORTING YOU CAN CHECK
A board drawn from checks, not from a status someone remembered to update.
Every state above comes from a check that ran, and every check is stored with the time it was taken.
A check runs every minute for each project you register
Every result is stored with the time it was taken
Ninety days of history, including the days that went badly