Service Restart Delay Calculator
Calculate maximum restarts within a rate-limit interval given RestartSec and StartLimitBurst.
Inputs
Max Restarts Within Interval
5
Status
All 5 allowed restarts can occur within the 60s window (taking 20s) — after that, systemd enters the failed state and stops restarting until the interval resets.
Time to Exhaust Full Burst (s)
20.0
Burst Limit Reachable Within Interval?
true
Step by step
Values used
RestartSec (seconds between restart attempts) = 5; StartLimitBurst (max starts allowed) = 5; StartLimitIntervalSec (rate-limit window, seconds) = 60
Time to exhaust the restart burst
time_to_exhaust_burst = (StartLimitBurst − 1) × RestartSec
Max Restarts Within Interval
= 5
Status
= All 5 allowed restarts can occur within the 60s window (taking 20s) — after that, systemd enters the failed state and stops restarting until the interval resets.
Time to Exhaust Full Burst (s)
= 20.0
Burst Limit Reachable Within Interval?
= Yes
How it works
systemd's crash-loop protection combines three settings: RestartSec (delay before each restart attempt), StartLimitBurst (max start attempts allowed) and StartLimitIntervalSec (the rolling time window StartLimitBurst is measured against) — if a unit is (re)started more than StartLimitBurst times within StartLimitIntervalSec, systemd marks it failed and stops auto-restarting until the window ages out. This calculator checks whether RestartSec's pacing would let the full burst count actually occur within the configured interval, or whether the interval resets first (making the burst limit effectively unreachable under pure RestartSec-paced restarts alone) — important for correctly tuning crash-loop protection rather than assuming StartLimitBurst always triggers as expected.
Formula
Time to exhaust the restart burst
time_to_exhaust_burst = (StartLimitBurst − 1) × RestartSec
- B
- StartLimitBurst
- R
- RestartSec
Frequently Asked Questions
What happens when a systemd service exceeds StartLimitBurst?
The unit enters the 'failed' state (visible via `systemctl status`, showing a start-limit-hit condition) and systemd stops attempting further automatic restarts, even if Restart=always is set — you must manually run `systemctl reset-failed <unit>` (and fix the underlying issue) before it will resume normal restart behavior.
Why might increasing RestartSec make crash-loop protection less effective?
If RestartSec is large enough that the time to reach StartLimitBurst restarts exceeds StartLimitIntervalSec, the interval window rolls forward and resets the count before the burst limit is ever reached — meaning the service can restart-loop indefinitely at that slower pace without ever tripping the 'failed' safeguard, which may or may not be the intended behavior.
How do I tune these settings for a service that occasionally needs a few retries but shouldn't loop forever?
A common pattern is a short RestartSec (a few seconds, for fast recovery from transient failures) paired with a StartLimitBurst/StartLimitIntervalSec combination sized so genuine crash loops trip the limit within a reasonable time (e.g. burst=5 within intervalSec=60), giving quick recovery from blips while still catching persistent crash loops.