What does the Background Sync API's `sync` event give you that retrying a failed request inside the page does not, and how do you register one?

## The problem A user taps *Save* in a tunnel. The request fails. You can retry in the page — a timer, a listener on the `online` event — but every one of those strategies has the same defect: it lives in the document. The user closes the tab, the OS reclaims the process, or they simply switch apps and the tab is discarded. The write is lost, and worse, it was shown as accepted. Background Sync exists to move that responsibility to the browser, which outlives the page. ## Registering ```js async function queueWrite(record) { await saveToOutbox(record); // durable local store first const registration = await navigator.serviceWorker.ready; if ('sync' in registration) { await registration.sync.register('outbox-flush'); } else { void flushOutboxNow(); // fallback path } } ``` `registration.sync` is a `SyncManager`. `register(tag)` takes a string tag; registering the same tag again while one is pending coalesces — you get one pending sync, not two. That is a feature: the tag names *work that needs doing*, not an individual item, so the handler should drain a queue rather than expect a payload. There is no way to attach data to a registration, which is why the durable store comes first and the tag merely says "there is something to flush". ## Handling ```js self.addEventListener('sync', (event) => { if (event.tag !== 'outbox-flush') return; event.waitUntil( flushOutbox().catch((err) => { if (event.lastChance) reportPermanentFailure(err); throw err; // reject → browser retries }) ); }); ``` Three properties of the event carry the semantics. `event.tag` identifies which registration woke you — one listener typically serves several tags. `event.waitUntil(promise)` both keeps the service worker alive while the work runs and reports the outcome: **resolve means done, and the registration is cleared; reject means not done, and the browser will try again** with backoff over a limited window before giving up. `event.lastChance` is `true` on that final attempt, which is your cue to surface a durable failure to the user rather than silently dropping the work. The browser may fire the event almost immediately if the device is already online, so the handler must be correct in the trivial case too, not only after a real outage. ## What this demands of the request Because the browser decides how many times to run your handler, every operation it performs must be safe to repeat. A `POST /orders` that creates a row per call will create duplicates the first time a response is lost after the server processed it. The standard answer is an idempotency key generated when the record enters the outbox and sent with each attempt, so the server can recognise a replay. This is the part candidates most often miss: Background Sync makes retries *more* likely, so it raises the bar on idempotency rather than lowering it. ## Periodic Background Sync is a different thing `registration.periodicSync.register('news', { minInterval: 24 * 60 * 60 * 1000 })` fires a `periodicsync` event on a browser-chosen cadence, for refreshing content rather than flushing writes. It is gated far more tightly — it generally requires an installed app, is subject to a `periodic-background-sync` permission and to the browser's engagement heuristics, and the `minInterval` is a floor the browser is free to ignore upward. Do not confuse the two in an answer: one-off `sync` is for work the user already asked for; `periodicsync` is for speculative freshness. ## Support As of 2025 `SyncManager` is implemented in Chromium browsers only; Safari and Firefox do not ship it. That does not make it useless — it means the design is a ladder. The outbox in durable storage and a foreground flush are the base everyone gets; Background Sync is the extra reliability Chromium users receive on top. Feature-detect with `'sync' in registration` and never let the base path depend on it.