Make sure you bind the address to 0.0.0.0

Thanks for looking into this. To confirm: gunicorn is already bound to 0.0.0.0, not a

narrower interface — this is in the original report, but to make it explicit:

[INFO] Listening at: http://0.0.0.0:8080 (1)

This is the exact log line from the container on every failed deployment. The healthcheck

still fails 14/14 attempts despite this. The evidence that points away from a bind-address

issue specifically: gunicorn's own worker-timeout watchdog never killed/respawned the

worker during any failure window (it would have, roughly every 30s, if a request had

actually reached it and hung) — meaning the healthcheck requests don't appear to reach the

container's network stack at all, not that they arrive and get rejected by a wrong bind

address.

Also worth re-flagging from the original report: deployment b1d132c7's own build logs show

"[1/1] Healthcheck succeeded!", yet that same deployment was marked failed and removed —

your own two data sources disagreeing with each other. That inconsistency seems like the

more promising thread to pull on. Happy to share full deployment logs if that would help.

On the healthcheckTimeout: we did have it at the default 300s for the first six failures

across 2026-08-05 and 2026-08-06 — every one of those ran the full 5-minute window with all

14 attempts failing, and the worker was never hit by a single request throughout (per the

gunicorn watchdog evidence above). Since a longer window produced the same zero-success

outcome every time, we shortened it to 60s specifically to reduce the outage window, not to

risk cutting off a deployment that might have eventually succeeded — we have direct evidence

across multiple full 300s windows that it doesn't. Happy to set it back to 300s temporarily

for a specific test attempt if that would give you better data to look at, just let me know.

Update: we found and fixed the root cause on our side, confirmed on a real deploy just now.

It was our own SECURE_SSL_REDIRECT setting (added in a recent release) — Django was redirecting

your healthcheck prober to https://... instead of returning 200, because that prober appears to

connect directly to the container rather than through the public edge that sets the header Django

uses to detect HTTPS. Added a specific exemption for our healthcheck path, redeployed, and it

passed cleanly (your own build log even showed "[1/1] Healthcheck succeeded!" this time, matching

the actual outcome).

The one thing from this thread I'd still flag as worth your team looking into separately: deployment

b1d132c7-0df2-4159-9767-e4ed33f3203f's build logs showed "Healthcheck succeeded!" while the

deployment itself was marked failed and removed — that inconsistency between your build logs and

final deployment state seems like a real, independent issue on your side, unrelated to our redirect

bug. Happy to share more detail on that specifically if useful, otherwise this thread can be closed

on our end.

Thanks for the help pointing us toward the bind-address/timeout checks along the way.