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

Delivering on DORA-style delivery metrics and service-level objectives (SLOs) does not require external infrastructure such as Prometheus or a dedicated observability stack. On Cloudflare Workers, the two essentials for SLOs are already in place: an execution environment and a durable store. This post introduces the P31 approach, which utilizes telemetry rows within D1, a cron worker for data aggregation, and a burn-rate dashboard based on plain SQL.

Every request contributes a row to the api_usage table, capturing details like method, route, status, latency, and timestamp. This straightforward data collection serves as the foundation for both availability and latency percentiles, without any additional complexity. The cost of storing this raw data is minimal.

To calculate error rates, an error budget window of 30 days and a target availability of 99.9% are used. The SQL query counts total requests, sums the number of 500 errors, and calculates the error rate. With an error budget of 43 minutes per month, the worker classifies burn rates as fast, slow, or ok. Fast burn, consuming the budget at multiple rates, triggers an immediate response. Slow burn, indicating a gradual decline, prompts a review, while ok requires no action.

The cron worker executes on the Cloudflare platform using p31-ci, enabling a seamless pipeline from api_usage rows to SQL rollup and updating the status page. No external infrastructure or third-party dependencies are necessary. The entire setup can be replicated within a day, and you can eliminate your observability vendor altogether.

The starting three SLOs are availability (99.9%), p95 latency, and p99 latency. These core metrics provide a solid foundation, with the possibility of refining them based on specific requirements.