{
  "id": 9873669,
  "title": "Exponential Backoff vs. Fixed-Interval Retries: When Growing Wait Times Actually Help",
  "url": "https://urgent.news/2026/09/26/exponential-backoff-vs-fixed-interval-retries-when-growing-wait-times",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-26T00:26:28.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/susumun/exponential-backoff-vs-fixed-interval-retries-when-growing-wait-times-actually-help-1dj"
  },
  "original_language": "en",
  "account": "Exponential backoff is a retry strategy that increases wait times between attempts exponentially, rather than keeping them constant. This technique is often used when many independent clients are simultaneously retrying against the same shared resource. By spacing out the retries exponentially, the load on the server is reduced, allowing it to recover from a surge in requests, a situation sometimes referred to as a \"thundering herd.\"\n\nHowever, exponential backoff isn't always the best approach. In the provided codebase, there are three instances where fixed intervals were chosen instead of exponential backoff, and reasons for these choices are explained.\n\nFirst, a function checks an HTTP status before and after WordPress updates. If the status is 0, indicating a failure prior to the response, the function attempts a single retry after a flat 3-second delay. If the status is a 5xx error, the function doesn't retry at all, treating the response as a genuine server-side problem. This approach is used because the function is called multiple times during a single maintenance run, and unpredictable total time could impact the scheduling of the run. One fixed retry is sufficient to distinguish a momentary blip from a genuinely down server.\n\nSecond, another section of code polls for a file lock by fixing an interval of 0.1 seconds until either the lock is acquired or 10 seconds pass. There is no exponential growth in the interval, as this lock is contested by at most two processes belonging to the same application. Polling at a short fixed interval allows the lock to be picked up close to when it's released, preventing unnecessary long gaps when the lock happens to become available.\n\nLastly, a third section uses an alternative approach to retrying. When fetching a plugin list, the first attempt runs WP-CLI without the --skip-plugins flag to allow any plugin's update-detection hook to run. If this attempt fails, the code immediately switches to a safer command that skips plugins, with no delay between attempts. This approach doesn't rely on waiting longer and longer, as the contention pattern is limited to two processes belonging to the same application, and the cost of frequent polling is just a bit of wasted CPU wake-ups, not risk to a shared resource.",
  "summary": "How to retry a failed operation is a design question every network-facing piece of code eventually has to answer. The textbook technique is exponential backoff — doubling the wait time on each retry — but it isn't automatically the right answer everywhere. This post works through what problem exponential backoff actually solves, then looks at three real retry paths in this app's own code where…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}