You can now write a good log event and locate a failure in the right layer. This lesson zooms out from single incidents to the living system: is Research Desk actually healthy right now, and who finds out first when it is not — you, or your users?

Health is nine questions, not one

"The homepage loaded once on my laptop" proves almost nothing about production. A genuinely healthy small app answers all of these:

• Availability: does the public URL answer successfully?
• Error rate: what share of requests return 500s?
• Latency: how slow are the slow requests getting?
• Provider health: are the market-data and model providers answering within budget and timeout?
• Queue backlog: are background refresh jobs completing, or piling up unprocessed?
• Database / storage: are we near connection, row, or disk limits? Are policies denying legitimate users?
• Model / API spend: is usage tracking toward an unexpected bill?
• Auth health: are sign-ins succeeding at the normal rate, or failing in a cluster?
• Backup / restore confidence: could we actually recover the database if we had to?

Miss any one and the failure surprises you. That is the recurring lesson from Part VII on infrastructure, and it is why OWASP's logging and alerting guidance treats missing detection — not just missing logs — as a security failure: an attack or outage nobody notices is one that keeps working.

The deployment can be live while everything else is dying

Connect this directly to your infrastructure map. Each of these is a real Research Desk scenario where the homepage loads fine:

• The web deployment is green, but the refresh worker crashed overnight — briefs are going stale and nobody was told.
• The worker is running, but the queue is growing — jobs enqueue faster than they complete, so latency climbs for hours before anything errors.
• The database is up, but a policy change denies owners their own watchlists — reads succeed, writes fail, and only the watchlist.edit.denied spike reveals it.
• The code is fine, but the provider key expired — every refresh returns an auth error from the provider, which your route faithfully converts into 500s.

In each case a single uptime probe says "all good" while the product quietly breaks. Health means watching the worker, the queue, the policy outcomes, and the provider — not just the landing page.

Three minimum alerts plus a spending guardrail

A small app needs exactly three alerts to start. Add more only when these three are trusted:

1. Public URL down. An uptime check probes the homepage (and one key API route) every minute. If it fails repeatedly, someone is notified immediately. This catches total outages, expired certificates, and crashed deployments. 2. Sustained server-error spike. If 500s exceed a small threshold — say 5% of requests for 10 minutes — notify the owner. One stray 500 is noise; a sustained spike is a broken route, a dead provider, or a bad deploy. 3. Critical background job repeatedly failing. If the refresh job fails several times in a row, or the queue depth passes its normal high-water mark, notify the owner. Background failures are invisible to uptime checks by design.

Then add the guardrail vibe-coded apps most often skip: budget / usage alerts. When a paid provider or model API could run away — a retry loop hammering refreshes, an agent calling the model in a tight loop — set a spend or call-count alert well below the painful number. A surprise bill is an operational incident too.

Alert fatigue: the alert nobody reads is not an alert

If every harmless warning pages someone at midnight, people stop looking — and then miss the real fire. Before enabling any alert, name four things:

• Severity: does this wake someone up, wait for morning, or just log for weekly review?
• Owner: exactly one person (or role) is responsible for the first look. "Everyone" means no one.
• Expected response: the first action, written down — "check deployment status, then provider status page, then recent commits."
• Escalation: what happens if the owner cannot fix it in the agreed time — who is next, and how are they reached?

A severity ladder most small teams can reuse: *critical* (wake up: site down, data at risk), *major* (same-day: error spike, job failing), *minor* (weekly review: slow latency drift, single transient timeout). Only critical pages. Everything else waits its turn.

Practical exercise: build your operations table

Create a small operations table for your app — six columns, four rows to start:

Adapt the thresholds to your traffic — a tiny app may use absolute counts ("more than 20 errors in 10 minutes") instead of percentages. The shape matters more than the numbers: every signal names its trigger, its destination, its human, its first move, and its backup.

Finish line: a health checklist or tiny dashboard covering availability, errors, latency, provider, queue, and spend — plus this operations table, plus one intentional test of a non-production alert path. Trigger a test alert against staging or a preview deployment and confirm it reaches its destination. An untested alert is a hope, not a control.

Common failure mode: seven alerts, no owners, all firing weekly. If that is your state, delete down to the three minimum alerts above, assign one owner each, and re-add the rest only with severity and escalation attached.

Check your understanding

1. Why can the homepage load fine while Research Desk is operationally unhealthy? Name two scenarios. 2. What are the three minimum alerts for a small app, and why does each need a spending guardrail beside it? 3. What four things must be named before an alert is enabled, and why does alert fatigue matter?

You now have the full observability arc: write trails worth following, read the right layer, and watch the system's health while you sleep. Class 52 puts this foundation to work — turning evidence-first habits into AI-assisted debugging that fixes causes instead of spraying patches.