Your Feature Request

I posted this in the HAProxy community, but was advised by lukastribus there to carry that into the issue tracker here for further discussion, copy & paste follows:

If I understood various sources correctly, there is currently no healthchecks for old processes remaining from a process rollover.

While the workaround of

hard-stop-after n

may be suited to wait a little and hard-stop the remaining connections, would not not be useful to have an optional setting to explicitly enabled healthchecks for old processes and couple that with

on-marked-down shutdown-sessions

where long running connections would remain on the old process,fully health-checked, but when the state of the backend changes, they would get actually cleanly stopped (idle clients would immediately know that the connection is ended).

The use-case I am thinking of is where the backends are using a healthcheck to designate for example the leader of a cluster who can write

frontend write
    mode tcp
    use_backend write

backend write
    option httpchk GET /read-write
    http-check expect status 200
    server db1 10.0.0.1:5433 maxconn 100 check port 8000
    server db2 10.0.0.2:5433 maxconn 100 check port 8000

In the above example, db1 or db2 will be the leader depending on their http services response on port 8000. The other will be DOWN.

But that status might change after some time. If a process rollover happened in the meanwhile, the old process(es) will not see the UP/DOWN change and not act on it, sending write workload to a then-read node.

What are you trying to do?

Healthchecks would be enabled explicitly for backends or upstreams even if they are connected via old leftover processes.

Output of haproxy -vv

HAProxy version 2.8.20-1ppa1~jammy 2026/03/21 - https://haproxy.org/