Skip to content
Adventive Adventive Engineering

Status Dashboard

The status dashboard is the operator-facing health surface for the Adventive edge, served at status.adventive.dev by the adventive-status-worker Cloudflare Worker. It answers two questions at a glance: is every service healthy, and where in the Cloudflare→Tunnel→AWS path is a problem.

Surfaces

Section titled “Surfaces”

The Worker serves two views of the same data plus a small API:

RouteWhat it is
/ and /mapNetwork Operations map (default) — a live SVG topology of the Cloudflare edge, the cloudflared tunnel hosts, and the AWS databases, laid out by us-east-1 availability zone with per-connector latency and health.
/statusClassic status table — the traditional component/incident list, grouped by service, with latency sparklines.
/api/v1/statusPublic JSON rollup of component and overall status.
/api/v1/topologyThe map’s data feed: the AWS snapshot (hosts + databases with their AZs) joined to the current Hyperdrive/tunnel check results.
/api/v1/internal/*Heartbeat, snapshot, and the on-demand AWS collector run — kept under /internal so they’re out of the public API surface.
/admin/*Admin surfaces, gated at the edge by Cloudflare Access.

A header toggle switches between the Map and the Status table; the map is the default landing page, and the table is expected to be retired over time.

The Network Operations map

Section titled “The Network Operations map”

The map renders the whole request path as a live graph: the Cloudflare edge (with WARP ingress) on the left, the AWS us-east-1 region on the right divided into its availability-zone lanes, the cloudflared tunnel hosts and each database placed in their real AZ. Links are colored and animated by health and latency; clicking any node or path opens a detail drawer. Filters show or hide classes (tunnel hosts, databases, workers) and environments (production, development, staging).

The map is a self-contained HTML document embedded in the Worker bundle (packages/worker/src/routes/map-page.ts) and served directly at /map — it does not depend on the static-asset pipeline, so it deploys with the Worker and is immune to asset-redirect handling. It self-refreshes against /api/v1/topology every 45 seconds and falls back to its last-known-good baked snapshot if the feed is unavailable.

How the data is collected

Section titled “How the data is collected”

Everything on both surfaces derives from checks and an AWS snapshot, stored in the Worker’s bindings and refreshed on a schedule:

  • Checks run on a one-minute cron. HTTP probes hit public endpoints; tunnel probes confirm each cloudflared connector; Hyperdrive probes open a real connection through each per-role connector (adv-hd-<db>-<role>-<env>) and time a round-trip. Results land in D1 (checks, check_results).
  • AWS topology is refreshed every five minutes by a read-only collector that calls the EC2 and RDS describe APIs (signed with SigV4 from a least-privilege IAM user, credentials resolved from Cloudflare Secrets Store). It records each tunnel host’s instance ID, private IP, security group, and availability zone, and each database’s AZ, engine, class, and endpoint. The snapshot is cached in KV.
  • The public page and the map read the rolled-up snapshot; /api/v1/topology joins the AWS snapshot to the live check results so the map can place real latency on real nodes.

Where it lives

Section titled “Where it lives”
  • Worker source: adventive-status-worker (Adventive/adventive-status-worker). Hono app; D1 + KV bindings; per-role Hyperdrive bindings for the probes; OTel via the standard wrapper. Deploys from a sandbox with wrangler deploy --env dev.
  • Infrastructure: the DNS record, Worker route, and Cloudflare Access app for status.adventive.dev are provisioned by the infra/cloudflare-status-worker Terraform module in adventive-platform-infra — see the Infrastructure as Code page.
Section titled “Related”