bunkr

Bunkr service-level objective · published commitment

Status · published commitment for the closed beta Version · 1.1 · 2026-06-12 · probe configuration specified (§3) Owner · Bunkr ops

This is the uptime commitment MASTER_PLAN §G5 requires published before the founding-50 cohort onboards. It is referenced by the terms of service §6.

1 · The commitment

99.5% monthly uptime during the closed beta.

The error budget is 0.5% of a month · about 3 hours 39 minutes per 30-day month.

2 · What "up" means

The platform counts as up when both hold:

  1. /api/health returns 200 · the route verifies Supabase env wiring and a live database round-trip, so a passing check means the app server AND the database answered.
  2. Signed-in users can execute the core loop · load the dashboard, open an RFQ, submit or read a quote, open a deal.

A failure of either counts the minute against the budget. Degraded-but-working (slow responses, delayed notifications) does not count as down but is logged and reported.

3 · How it is measured

  • External probe · an uptime monitor calls /api/health on a fixed interval from outside our infrastructure. The probe interval defines measurement resolution · a failed probe marks the interval down until the next success.
    • Configuration (Stage 47) · UptimeRobot free tier · monitor type HTTP(s) · URL https://www.bunkr.ae/api/health · 5-minute interval (free-tier floor · resolution ±5 min against a 3h39m monthly budget is adequate) · keyword check optional ("ok":true) · alert contact = the ops email. Operator sets this up once in the UptimeRobot dashboard; no code involved. Re-check green on launch morning (runbook §12 step 4).
    • Cron watchdog · /api/cron/watchdog (Vercel Cron, daily 05:30 AM GST) asserts each of the six pg_cron jobs has a successful run in the last 25 hours and emails ops on staleness · covers the scheduled half of the platform the HTTP probe cannot see.
  • Internal evidence · Sentry error rates and Vercel/Supabase status history corroborate or contest probe data when a dispute about a window arises.
  • Operational KPIs · the nightly slo_metrics rollup (migration 038) snapshots RFQ-to-quote time, award-to-delivery time, payment-confirmation delay, and dispute rate (median · p90 · sample size) onto the ops dashboard. These are product service levels, not uptime · they are published for transparency and have no contractual remedy attached.

4 · Exclusions

  • Scheduled maintenance · announced in-app in advance, executed in a stated window. The window does not count against the budget.
  • Force majeure and upstream regional failure · a documented outage of an entire hosting region (AWS ap-south-1 during beta) is reported but excluded. A failure of our own configuration on healthy infrastructure is NOT excluded.
  • A customer's own network or device.

5 · Reporting and remedy

  • Misses are published · when a month closes below 99.5%, the number, the cause, and the fix land in the ops log and active accounts are notified in-app.
  • During the free beta the remedy is that transparency (terms of service §6.3). Service credits arrive with paid tiers, on the schedule published with them.

6 · Review

The target is reviewed at the G5 gate review (Stage 45) and at every gate after. Tightening the target requires one full month of measured headroom above the proposed number. The in-UAE migration (session-2 runbook) re-baselines the measurement · the first post-migration month is reported but not counted against the budget.