Intermittent Heartbeat Timeouts with Self-Hosted Runners on Legacy Hardware (ProLiant DL320)

[Carol James]

Hey everyone,

I’ve been a long-time user of Atlassian tools, but I’ve recently run into a bit of a head-scratcher while trying to optimize our local CI/CD setup, and I was hoping to get some perspective from others who might be doing something similar.

To give some context, I’ve always been a fan of repurposing enterprise gear for development environments rather than jumping straight to expensive cloud minutes for every single build. Currently, I’m using a ProLiant DL320 as a dedicated host for our Bitbucket Runners. For a 1U server, it’s usually incredibly reliable, and there is something genuinely satisfying about hearing those fans spin up the moment a pull request is merged and the pipeline kicks off. It makes the whole "infrastructure as code" thing feel a lot more tangible.

However, I’ve hit a specific point of frustration: I’m seeing intermittent "Runner connection lost" errors, specifically during the "Step teardown" phase or during very high-load Docker builds.

I’ve been monitoring the system resources on the DL320, and while the CPU spikes are expected during a heavy compile, the Bitbucket Runner service seems to lose its heartbeat connection to the cloud almost immediately when the load average climbs. It’s strange because the network itself stays up—I can still SSH into the box without a hiccup—but the runner agent seems to deprioritize its own telemetry, leading Bitbucket to assume the host has gone offline.

I’ve already tried a few things, like pinning the runner to specific cores and even tweaking the OOM killer settings to make sure the agent doesn't get nuked by the OS, but the "connection lost" issue persists. It’s particularly annoying because the build usually actually completes on the hardware, but Bitbucket marks the whole step as "Failed" because it didn't receive the final status update.

I’m curious if anyone else has experienced this kind of sensitivity with self-hosted runners on older, single-socket enterprise hardware. Is the heartbeat mechanism just that sensitive to CPU starvation, or could it be an issue with how the runner interacts with older NIC drivers under heavy I/O load?

Has anyone found a way to "buffer" that connection or perhaps give the runner service higher process priority without completely starving the actual build containers? I’d hate to give up on using the DL320 for this, as it's otherwise the perfect size for our small rack.

Looking forward to hearing your thoughts or if I'm just shouting into the void with this hardware setup!