Make the app tell you when it's healthy — and shout when it's not.
Module 11 · Health checks, logs, metrics, and alerts.
Advanced Observability Includes Lab ~50 minPrerequisites: Module 10 (a deployed vault). Deep dive: DevOps Lab: Monitoring & Logging.
Your app is live — but is it up right now? Serving errors? Slow? Out of memory? Without observability, you find out when a user complains. That's the last of the six failure modes, at production scale: silent breakage nobody sees.
| Pillar | Answers |
|---|---|
| Logs | What happened? (a searchable record of events) |
| Metrics | How much / how fast? (numbers over time: requests, errors, latency) |
| Health checks | Is it up right now? (a simple yes/no endpoint) |
| Alerts | Should a human care now? (automatic notifications) |
The simplest, highest-value observability: a /health endpoint that returns OK when the app can serve requests. Uptime monitors and orchestrators ping it constantly — if it stops answering, they know instantly.
Point a free uptime service at /health and you'll get an email/SMS within a minute of your app going down — before most of your users even notice.
Log as structured data (JSON), not random strings, so you can search and filter. Include request, status, and duration — and never log secrets or full personal data.
Expose a /metrics endpoint of counters and timings; Prometheus scrapes it, Grafana graphs it. Request rate, error rate, and latency (the "RED" metrics) tell you the app's health at a glance.
The DevOps Lab Monitoring module ships a working Prometheus + Grafana setup and a dashboard JSON. Reuse it against the vault rather than wiring monitoring from scratch.
Dashboards only help if someone's looking. Alerts flip that: define a rule ("error rate > 5% for 5 minutes", "/health down") and get notified automatically. Good alerts are few, meaningful, and actionable — alert fatigue is real.
Page a human for "users can't create snippets," not "CPU hit 70% for a second." Every alert should mean "a person needs to act." The rest belongs on a dashboard.
You'll add a health check, structured request logging, and at least one metric — then watch your own app report on itself.
Your deployed snippet-vault from Module 10.
Add a GET /health endpoint returning status and uptime. Add a test for it. Review, commit.
Review the diff — confirm nothing sensitive is logged.
Add a /metrics endpoint (Prometheus format) with at least a request counter. If you want the full picture, wire in the DevOps Lab's Prometheus + Grafana against it.
Hit the app a few times, then check /health, your logs, and /metrics. Point a free uptime monitor at /health for real alerting.
In REFLECTION.md: what's the first thing you'd want an alert for, and why? Commit.
Your snippet-vault repo. Self-check:
/health returns status; it has a test/metrics endpoint exposes at least one metricREFLECTION.md names your first alert| Term | Plain meaning |
|---|---|
| Observability | Being able to understand what your running app is doing from outside. |
| Health check | An endpoint that says whether the app is up. |
| Structured log | A log entry as data (JSON) you can search and filter. |
| Metric | A number tracked over time (requests, errors, latency). |
| Alert | An automatic notification when a rule is breached. |
A deployed app that reports its own health, logs what it does, exposes metrics, and can alert you when something's wrong. That's the full DevOps loop — and the last of the six failure modes, closed.
Next up: Module 12 — Capstone: Idea → Shipped. You'll take a brand-new idea through this entire lifecycle on your own — the portfolio piece that proves you can vibe-code and ship like a professional.