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
Cloudflare D1
Cloudflare Email Routing
- release-please
GitHub Actions