Internal demonstrator
SiteGuard Monitor: service-health and alerting demonstrator
We implemented Python/SQLite probes, durable health observations and a status view, then exercised the alert states with synthetic failure sequences.
01
Failure symptom
02
Trace / logs
03
Fix + regression test
Verify rollback and recovery
Trace, correct and rerun the failing operation.
RESOURCES / ENGINEERING STORIES
The problem, the change and the evidence.
An internal Python and SQLite monitoring prototype using simulated service-health checks.
The implementation records health observations and exposes the status transitions needed to investigate a failed check.
Explore the system, engineering decisions and observed outcome in the sections below.
Project context: An internal Python and SQLite monitoring prototype using simulated service-health checks.
Architecture and trust boundaries
A reviewable system path
Internal demonstrator — synthetic service-health observations only.
STEP 1 / 4
Synthetic HTTP/service fixture
STEP 2 / 4
Local Python probe
STEP 3 / 4
SQLite observation history
STEP 4 / 4
Operator-facing alert view
Trust boundary / failure mode
Failures and timestamps are synthetic; alert delivery, real multi-region probes and SLO accuracy were not validated.
What evidence supports it?
Repeat deterministic success/failure inputs and inspect stored status transitions. No production customer is implied.
Problem
- A successful HTTP request alone does not establish a healthy dependency or an actionable incident signal.
- Operators need enough history to distinguish a brief outage from recurring failures or a noisy check.
Engineering work
- Developed a local probe workflow for checking service responses and recording observations in SQLite.
- Exposed uptime history and alert-oriented status in a small demo interface.
- Kept synthetic failure conditions separate from genuine production traffic so tests were repeatable.
Engineering validation
- Used synthetic success and failure responses to exercise state transitions and stored observations.
- Checked that observed failures could be surfaced for inspection and correlated with the recorded timeline.
- For any production adoption, additional tests would be required for retries, clock skew, false positives, notification delivery and alert fatigue.
Results
- The implementation records health observations and exposes the status transitions needed to investigate a failed check.
- The local prototype was tested with simulated failures; alert delivery and production reliability would require additional validation.
Related engineering stories
First-party operational work
Repairing a Cloudflare Worker canonical-URL redirect loop
Read case study →
Experience-based architecture overview
Mobile and backend workflows across multiple operational sites
Read case study →
