RenderMac

System status

Checking…

Live health is polled directly from the two public, unauthenticated control-plane endpoints (GET /healthz and GET /v1/services) every 30 seconds from your browser — the same calls any buyer or provider can make themselves. No status is fabricated or cached server-side.

Components

Each card reflects the most recent successful (or failed) call to the named endpoint from this browser session.

Control-plane APIChecking
Waiting for first check…
DatabaseChecking
Inferred from /healthz, which executes SELECT 1 against Neon Postgres before responding.
Service catalogChecking
Waiting for first check…
Provider gateway (WebSocket)No public probe
The provider WebSocket at wss://api.rendermac.com/v1/provider/ws requires a paired device credential to connect, so this page cannot probe it without exposing a credential. Gateway session counts are visible to admins at /admin/api/overview.

SLO targets — private-pool dogfood phase

These are RenderMac's internal operating targets for the current private-first-party and org-private pools, not a contractual SLA. RenderMac has not yet stood up an external uptime-history monitor (see "About these numbers" below), so this page shows the documented target next to live current health rather than a fabricated 30/90-day percentage.

API availability
99.5% / month target
Measured as successful /healthz responses. Dogfood-phase target pending a public SLA once the public pool (see IMPLEMENTATION-STATUS.md's "Public supply" row) opens.
Job success rate (private pool)
≥ 98% of admitted jobs
Excludes buyer-cancelled jobs. Grounded in local qualification evidence: 50/50 sequential stitch jobs, 18/18 concurrent-fleet jobs — see docs/evidence/. Not yet measured against sustained production traffic.
Webhook delivery
≥ 99% within retry window
RenderMac retries a failed webhook delivery up to 8 times over 24 hours before recording it as a dead letter (see webhook_dead_letters, migration 013). Admins can inspect and requeue dead letters from the admin console.
About these numbers. RenderMac does not yet run an external, third-party uptime monitor that records historical incident/availability percentages — the targets above are documented operating goals set as part of production hardening, checked against live health on this page, not a retrospective measurement. Once real buyer/provider traffic accumulates on the public pool, this section will be replaced with actual trailing 30/90-day measurements sourced from that monitor, and any incident will get a dated postmortem entry here rather than a silently-updated percentage.
Raw /healthz response
Waiting for first check…
Never checked. Next check in 30s