DORA metrics + SLOs without external infrastructure: a Cloudflare Workers approach

You do not need Prometheus, a metrics SaaS, or a dedicated observability stack
to run DORA-style delivery metrics and service-level objectives. On Cloudflare
Workers you already own the two things SLOs need: an execution environment and
a durable store. This post shows the P31 approach: telemetry rows in D1, a
cron worker that rolls them up, and a burn-rate dashboard driven by plain SQL.

Every request appends a row to the api_usage table — method, route, status,
latency, timestamp. Nothing fancy, but it is the raw material for both
availability and latency percentiles, and it costs almost nothing to store.

-- error budget window: 30 days, target 99.9% availability
SELECT
  count(*) AS total,
  sum(status >= 500) AS errors,
  sum(status >= 500) * 1.0 / count(*) AS error_rate
FROM api_usage
WHERE ts > datetime('now', '-30 days');

The SLO is 99.9% availability, which yields roughly 43 minutes of allowed
downtime per month. From that budget the worker classifies burn as fast,
slow, or ok. Fast burn means the budget is being consumed at multiples of
the rate; it triggers the immediate channel. Slow burn is the quiet killer and
triggers a review. ok requires no action — and the p95/p99 latency numbers
ride along in the same rollup.

The cron runs on the platform via p31-ci (Cloudflare cron triggers), so the
whole pipeline is api_usage rows → SQL rollup → status page, with no external
infrastructure and no third-party dependencies. You can reproduce the entire
stack in a day and delete your observability vendor.

The three SLOs to start with: availability (99.9%), p95 latency, p99 latency.
Everything else is a refinement.