# Background worker stops processing after a connection interruption

**URL:** <https://community.fly.io/t/background-worker-stops-processing-after-a-connection-interruption/28868>\
**Category:** General\
**Tags:** redis\
**Created:** [October 19, 2026, 4:34pm UTC](https://community.fly.io/t/background-worker-stops-processing-after-a-connection-interruption/28868 "2026-10-19T16:34:15Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![mayailurus](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/mayailurus/32/17593_2.png) [@mayailurus](https://community.fly.io/u/mayailurus)\
**Post date:** [October 19, 2026, 5:36pm UTC](https://community.fly.io/t/background-worker-stops-processing-after-a-connection-interruption/28868/2 "2026-10-19T17:36:51Z")

</div>

Hi… Something like an inability to reach the Redis server wouldn’t have triggered the standby Machine, but if the underlying physical host stopped being reachable from the rest of Fly.io’s infrastructure, then that would generally cause it to step in. The exact rules for the standby Machines unfortunately aren’t really documented; the following forum post from June has the fullest description that I’ve seen to date…

[https://community.fly.io/t/standby-machine-what-happens-to-the-original-machine-when-its-host-recovers-after-failover/27995/4](https://community.fly.io/t/standby-machine-what-happens-to-the-original-machine-when-its-host-recovers-after-failover/27995/4)

Possibly the standby mechanism was intentionally disabled during the rolling reboots, to avoid further straining the system, 🤔. (They mentioned in the `gru` mega-thread that they were already short on capacity.)

The official docs _do_ have some brief suggestions on monitoring background workers in general, however:

[https://docs.fly.io/reference/health-checks#health-checks-for-apps-with-no-services](https://docs.fly.io/reference/health-checks#health-checks-for-apps-with-no-services)

> [@dev856](#):
>
> should our worker automatically reconnect afterward?

In the case of the fleet-wide reboots… If the Machine wasn’t set to auto-`suspend`, then it should have gone through it’s own, full boot cycle when the host rebooted. (However, the [status page entry](https://status.flyio.net/incidents/01M52RAWMVC0NKEBRDKC3VXT3K) did mention a special case when the Machine’s `restart` policy was set to a non-default value, now that I think of it.)

When it’s just a glitch in network connectivity to Redis (or similar), then it depends on the particular implementation of that background worker. The Python-based ones anecdotally do seem a little prone to hanging, although I don’t know that ecosystem very well.

[https://community.fly.io/t/celery-beat-process-hangs-silently-after-several-hours/25444](https://community.fly.io/t/celery-beat-process-hangs-silently-after-several-hours/25444)

You can look at the worker’s own logs (`fly logs` and/or [Grafana](https://docs.fly.io/monitoring/search-logs)) to see if there are any complaints about network, OOMs, timeouts, etc.

Hope this helps a little!

---

_[View the full topic](https://community.fly.io/t/background-worker-stops-processing-after-a-connection-interruption/28868)._