Monitoring and Health
Platform status
Live status and incident history: status.burdenoff.com.
Burdenoff continuously probes the gateways and core services behind FluidGrids and publishes the result there. Subscribe to the status page if you want to be told about incidents rather than discover them.
Health endpoints
If you front FluidGrids with your own uptime monitor, probe the gateway:
| Target | Endpoint | Expected |
|---|---|---|
| Workspace public gateway | /health/ready | 200 OK |
Probe no more than once a minute. Health endpoints are unauthenticated and return no workspace data.
Observing your own runs
Run-level observability lives in the product, not in an external tool:
| What | Where |
|---|---|
| Run status, duration, and per-node timing | Runs › run detail view (Timeline tab) |
| Node input/output and error payloads | Run detail view, per node; the Logs tab streams the full run log |
| Failure history and retry attempts | Runs list, filtered by status; attempt counts on each node |
| Programmatic access | GraphQL API and the FluidGrids SDKs |
Run logs are retained for the period stated in your plan. Export them through the API if you need longer retention or want them in your own stack.
Alerting on failures
Two options, depending on where you want the signal:
- In a workflow — start a workflow with an Error Trigger so it runs whenever another workflow fails and notifies you (email, chat, webhook, or anything reachable over HTTP); or turn on On Failure email / webhook notifications under the workflow module's Settings
- Outside FluidGrids — poll the GraphQL API for runs in a failed state, or subscribe to a webhook and forward it to your incident tooling