Practice page · Week 5 and Lumen Desk

A green health check is not adoption

A green /health means a process answered. It does not mean the reply was right, and it does not mean anyone used it. Health checks decide rollback. They do not decide cutover.

Extracted from Week 5: Deployment and CI/CD and the Lumen Desk case. Northline and Lumen Desk are fictional practice. Portfolio policy.

What the health check is for

In the lab's httpapi.py, GET /health returns 200 {"ok": true} with no token. A load balancer needs that. It must not call the model, and it must not require the application token. Otherwise a missing secret looks like a total outage, and it also locks you out of the check you need to debug the secret. test_health_is_open locks the open route. test_tasks_require_token_and_auth locks the other side: /v1/tasks needs the bearer.

Health checks decide rollback. If /health fails after a new task starts, the orchestrator keeps the old one. So check the dependency you cannot serve without. If /health always returns 200 even when the database is down, traffic goes to a process that cannot claim jobs. Do not check the model provider inside /health: a provider incident would mark every replica down, and nothing would be left to return a decent error.

What it cannot tell you

• Whether the status in the reply matches the source of truth.
• Whether a person used the new path, or kept using the old one.
• Whether any shopper was affected by a wrong answer.

The Lumen Desk call

In the fictional Lumen Desk case, the support lead, June Ibarra, planned to turn the old screen off on a Friday if /health was green. That plan was refused. The old screen stayed up for a parallel run. Adoption was counted as replies a person edited and sent from the new path, next to replies still sent on the old screen. Page views were not the count.

On ticket LD-18, the practice failure, the new path showed a status the old screen did not. Health was green the whole time. The test that matters is that a person can see the mismatch and that a five-line draft exists, unsent: what broke, who is affected, what you stopped, what you do not know, and when the next note comes. "No customer impact" because health was green is a bad note. A test that fetches /health and expects the old screen to disappear is the wrong test, even when the request succeeds.

What to do instead

1. Keep /health narrow: process up, the database it needs reachable, no model call, no token.
2. Keep the old path on during a parallel run. Cutover is a decision from the adoption table, not from a status code.
3. Count the action the buyer cared about. Opening a page is not that action. The table is allowed to say stop.
4. Watch replies, with a trace id on each one and no shopper email in the trace. Week 6 covers traces, alerts, and the incident note.
5. Practice the rollback on a quiet afternoon: run the previous image tag. If you have never done it, you do not have a rollback.

Go to Week 5: Ship

Last technically reviewed: October 2026. Tested with: Python 3, stdlib, SQLite, stand-in model. Not a live provider.