Skip to content
back to achievements

Case study · Proxy

Side projectProject period2026 – Present

Operable in production

Added question history in D1, email alerts through Cloudflare Email Routing, a version endpoint, release-please releases, a deploy smoke test, and rollback and backup runbooks.

01

Why

I run Proxy alone. Cloudflare's free plan has no error-rate or traffic-spike alert for Workers, so without my own monitoring I would find out about a problem from a visitor, or from a bill.

02

Decision

Every answered request is written to a database with its tokens, route and stage timings, and every request turned away is counted per day and reason, with no address and no text. A daily health job reads only those totals and fails, which makes GitHub email me, when a threshold is crossed: budget exhausted, cost above normal, too many refusals or failed verifications, service errors, or blank replies. The Worker itself emails me through Cloudflare Email Routing, at most once a day per event, with no third-party service or API key. Releases go through release-please, a deploy smoke test checks the new version, a version endpoint says what is live, and runbooks cover rollback and backups.

03

What I built

Added question history in D1, email alerts through Cloudflare Email Routing, a version endpoint, release-please releases, a deploy smoke test, and rollback and backup runbooks, so the service can be run and recovered without guesswork.

04

Trade-offs

  • It is logs, email alerts and commands, with no live dashboard, so there is no extra service to run or to watch.
  • The alert thresholds are starting guesses until there is real traffic.
  • A Worker rollback does not undo a database change, so migrations only ever add tables or columns.

05

Outcome

A quiet day sends nothing, a bad day sends one clear message, and a bad release can be rolled back from a runbook.

Technologies