Public stable responses
3×
Required consecutive HTTP 200s before acceptance.
Internal engineering case studyDjango, infrastructure and release engineering
Production engineering: making application readiness stricter than process state
Production releases needed to remain safe even when systemd reported a process active before its HTTP listener was ready, and when dependent worker lifecycle behavior differed from application service lifecycle assumptions.
Lancaster Solutions production platform
Evidence snapshot
The numbers this case can support.
Additional stability probes
5×
Five more public 200 responses after readiness.
Failure modes caught
2
Startup-listener race and dependent audit-worker lifecycle.
Schema changes
0
The final template release required no database/schema change.
Scope
What the work covered
- Exact Git SHA and file-scope qualification
- Rollback snapshots before production writes
- Django checks and migration-drift validation
- Serialized service transitions
- Explicit restoration of dependent background workers
- Correct Host/X-Forwarded-Proto origin probes
- Consecutive readiness/stability checks and nginx validation
Case detail
The first failure was a readiness race
The process manager reported the public service active before its listener was ready, producing a transient 502. The deployment was rolled back and the acceptance barrier was changed to require stable origin responses.
Case detail
The second failure exposed dependency semantics
Stopping the public portal correctly stopped its dependent audit worker, but restarting the portal did not restore the already-stopped worker. The final gate caught the missing dependency and the corrected deployment explicitly restored and stabilized it before acceptance.
See the same pattern?
Start with the current website or system—not a predetermined package.
Use the free website review for a public baseline or book a call when the issue includes hosting, campaigns, CRM, access, migrations or delivery operations.