Goal
Understand what belongs in operations versus in a resource detail page.Prerequisites
- At least one live resource
Workflow
1
Use operations when you want a platform-wide view instead of a single resource view.
2
Drill into services, alerts, and nodes depending on the operational question.
3
Treat recovery-state messaging as part of the operational model, not just a design flourish.
When to start in Operations
- Several services look unhealthy at once
- You need a fleet-level view before drilling into one resource
- You want to understand alerts, services, and node state together
What Operations is not
Operations is not a replacement for resource detail pages. It is the platform-wide orientation surface. Start there when the question is broad, then drill into the relevant project, stack, database, or node page when you need resource-specific evidence.Public reported status history (unreleased)
The status-page history connection is implemented but requires an API and frontend release. It needs no new migration, worker, node-agent update, or environment variable. After release, the public status page and GET /api/v1/status history show the worst reported state for each component on each of the last 90 UTC dates. Saved manual states carry forward until their recorded end; published incidents and non-cancelled published maintenance apply only to their affected components and time windows. Draft reports and future windows are excluded. Dates before records began remain unknown. Partial recording days are faded and labelled; today includes only elapsed time. A component with missing records does not dim other components. This is operator-reported history, not measured uptime or an SLA measurement. The existing observed_minutes and healthy_minutes fields remain zero for these reports.Expected result
You know where to look first when something feels wrong at a platform level.