Dashboards and monitoring
Dashboards is where you watch the sites you run. You group your sites, name the addresses on each one to check, and the hub checks them on a schedule and keeps the history of every check. A public status site shows the same information to anyone who looks.
You open Dashboards from a workspace, at /<workspace>/dashboards, and a product has Dashboards too.
Topics
- Site groups, sites and endpoints: the three layers, and what a check records.
- The status site: the public page for the hub's own fleet.
Everything Dashboards shows, a program can read and change over the API: the site groups and the sites in them, the endpoints to check and the history of checks.
Site groups, sites, endpoints and health checks are plain resources under the monitoring tag, each with list, create, read, update and delete. Nothing about them is hand-written.
The status site reads a public status summary from each environment's backend, one backend per environment. Each backend also answers a health call with its database pools and its uptime.
Over MCP, the monitored sites tool group lets an agent list site groups, sites and endpoints and read recent checks.
The full list of routes, with each one's parameters, body and responses, is the REST reference on the help site. The tools an agent gets are listed in the MCP reference.
Monitoring is a plain set of tables. Groups, sites, endpoints and checks are tables with no hand-written routes, because the schema says everything the API needs and the generated routes reach it.
A site group is an owned thing. It moves between workspaces the way a persona or a project does, with the same preview and the same record, because what you watch belongs to whoever runs it.
Status is public, and worked out from what is already known. The status site has no database of its own. It reads what the backends already know.