Consider closing DB connections explicitly in the default database health check

[ZhdanovAM72]

Hi!

In one of my deployments, the health check endpoint is hit every 10 seconds, while database connections remain alive for about 60 seconds. Under that pattern, connections opened by the health check were not being closed immediately and accumulated over time.

That resulted in a gradual increase in open database connections caused only by health check traffic. To avoid that, I introduced a custom database check that always closes the connection in a finally block after running the query.
Simplified version:

connection = connections[self.alias]
try:
    ...
finally:
    connection.close()

From my side, it seems the default database check could be safer if it explicitly closed the connection after each run, especially for deployments where:

• health probes are frequent
• DB connection lifetime is longer than the probe interval
• connection count is tightly constrained

I am not sure whether this should be the default behavior for everyone.

I ended up solving this with a custom check, but I thought it might be worth discussing whether the base implementation should handle this case more defensively.

[codingjoe]

Hi @ZhdanovAM72,

like this?

django-health-check/health_check/checks.py

Lines 136 to 137 in a922d34

	finally:
	connection.close_if_unusable_or_obsolete()

Thanks for reaching out. We have been closing connections since v3 and continue to do so in v4. Even though the latter users async methods, where Django handles connection closing for new threads.

Since you are experiencing connections from staying open, I'd recommend revisiting the documentation about persistent connections.

If you happen to use PostgreSQL, I highly recommend setting up PGBouncer to pool connections.

Please let me know if you have more questions about this topic.

Cheers!
Joe

[ZhdanovAM72]

Hi Joe,

Thanks for the clarification and for pointing me to that part of the code.

I see that django-health-check already calls:

django-health-check/health_check/checks.py

Lines 136 to 137 in a922d34

	finally:
	connection.close_if_unusable_or_obsolete()

From what I understand, this keeps Django’s normal connection lifecycle behavior and does not necessarily close a healthy reusable connection immediately. In my case, with frequent health probes and a non-zero CONN_MAX_AGE, that still led to health-check-related connections remaining open longer than I expected.

What worked well for me was using a dedicated database alias for the health check with CONN_MAX_AGE = 0, for example:

# Health checks use a dedicated short-lived connection so closing it does not
# affect the application's persistent default connection.
DATABASES["healthcheck_db"] = {
    **DATABASES["default"],
    "CONN_MAX_AGE": 0,
}

Then I run the DB health check against healthcheck_db instead of default.

This seems like a good compromise for my setup, since it keeps the application’s main connection behavior unchanged while making the health check connection short-lived.

One question for my understanding: is the reason for using close_if_unusable_or_obsolete() instead of an explicit close() mainly to preserve connection reuse and avoid the overhead of opening a new DB connection on every health check?

Thanks for your help!
Best,
Aleksandr

[codingjoe]

That's a very creative solution; thanks for sharing! We don't use multithreading directly anymore. However, Django's async_to_sync converter does. It should close connections when a thread shuts down, but that's out of my control.

[codingjoe]

@ZhdanovAM72 turns out there was room for improvement here; see #701 Version 4.2.2 should resolve this issue.

[ZhdanovAM72]

Thanks a lot @codingjoe , this really solved our problem and now we can use the health_check.Database class directly!