Topolo Status

What It Is

Topolo Status is the public status page for Topolo production surface health.

Architecture

The Status Worker serves the public page, exposes read-only health data, runs scheduled production probes, records status history in D1, and alerts operators when repeated probe failures cross the configured threshold.

Runtime Surfaces

See /systems/topolo-status for the current host, Worker, and service metadata.

API Reference

The anonymous Status API is read-only and centered on status-page rendering, GET /api/status, and the /api/health healthcheck. Credential-scoped operators can additionally poll the fleet and manage incident or maintenance lifecycles through the published Topolo actions.

Auth and Permissions

The public status surface is read-only. status:poll gates manual polling and status:write gates incident and maintenance mutations; those records live in the service's platform-owned system workspace.

Data Ownership

Topolo Status owns status incidents, probe history, and aggregate production-health telemetry. It does not own the downstream product data for the services it monitors.

Deployments

Topolo Status deploys as the production topolo-status Worker serving https://status.topolo.app.

Failure Modes

• monitored endpoint outage, DNS failure, or false positive
• D1 write failure for probe history
• alert webhook delivery failure
• route or Worker deployment drift

Debugging

Start with /systems/topolo-status, then check https://status.topolo.app/api/health, Worker logs, and recent status-history rows for the affected probe target.

Use It

Open Topolo Status for the human product surface. The system handbook records its current hosts, ownership, Auth scopes, storage, deployment, failure modes, and machine artifact.

Discover the credential-scoped automation surface before making an API call:

topolo services --query topolo-status --json
topolo actions --service topolo-status --json
topolo actions capabilities --service topolo-status --json

Choose an action, inspect it with topolo actions get <action-id> --json, then validate and plan a published example. The Agent Actions reference exposes the same public schemas, effects, examples, verification, and recovery guidance.

Example workflow:

1. Confirm the active identity and organization with topolo whoami --json.
2. Discover Topolo Status and select one published action rather than guessing a route.
3. Inspect its input/output schemas and published example.
4. Validate and plan the exact payload; obtain confirmation for a mutation.
5. Execute and perform every published verification step.

Change Log / Verification

• Reconciled the public read surface and credential-scoped poll, incident, and maintenance actions against origin/staging on 2026-07-28.

• Reconciled this page against system-apps/TopoloStatus origin/staging 7dc28d7f2ab5 on 2026-07-24 after reviewing every docs-relevant commit since its previous verification watermark. Dependency-only currency commits were checked by the fleet production-dependency gate and did not change this page's product contract.

• Added public application coverage on 2026-06-28 so the public Status system no longer relies only on internal handbook coverage.

• Centralized Status app identity metadata on 2026-05-13 so runtime and CloudControl config no longer carry concrete app ids.

• Added canonical system coverage on 2026-05-02 from the CloudControl manifest and package metadata so the Docs registry covers the public status and monitoring Worker.