Stop getting burned by systemd’s default RestartSec timing

Technical Briefing | 9/30/2026

You spend all afternoon perfecting your service unit, you hit systemctl start, and it works perfectly. But then you simulate a crash, and you realize your service is flapping every millisecond because you didn’t think about restart backoff. If your app hits a database connection limit or an expired credential, systemd will happily hammer that endpoint thousands of times per minute until you get blacklisted.

Why the default behavior is a trap

By default, systemd restarts a failing service after 100 milliseconds. That is barely enough time for the process to even register its own death, let alone for the network stack to release the socket. If your application logic requires hitting a remote API, you are basically executing a self-inflicted DDoS attack every time your config is slightly wrong. I have seen more than one production database get locked out because a dozen microservices decided to retry simultaneously without any exponential delay.

[Service]
Restart=on-failure
RestartSec=5s
StartLimitIntervalSec=60
StartLimitBurst=3

• Increase RestartSec to something sane like 5 or 10 seconds to let the dust settle.
• Use StartLimitIntervalSec and StartLimitBurst to force a give-up after a few consecutive failures.
• Set StartLimitAction=reboot if the service is absolutely required for the node to be useful.

If you don’t define these limits, systemd just keeps trying forever. Eventually, your logs will get swallowed by the deluge of restart cycles, and you won’t even be able to find the original exception that caused the crash. Go check your current unit files; if they lack these stanzas, you are one bad deploy away from an incident you created yourself.