Wiki · Concept · Last reviewed June 25, 2026

Background Sync API

The Background Sync API lets a web application register deferred service worker work so network actions can be retried later when connectivity is available.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: browser API, service workers, offline queues, agents, audit trails

Definition

The Background Sync API is a WICG draft for registering one-off synchronization work on a service worker registration. The draft extends ServiceWorkerRegistration with a sync attribute that exposes a SyncManager. A page can register a named sync task, and the browser can later fire a sync event in the service worker.

MDN summarizes the use case as deferring server synchronization work until a later time, especially when a device is offline. Typical examples include queued form submissions, message sends, analytics batches, or other network requests that should not simply disappear when connectivity fails.

How It Works

A page first needs a registered service worker. It can then call registration.sync.register(tag), where the tag names the requested work. A service worker listens for the sync event and checks event.tag to decide what queued work to process. The worker uses event.waitUntil() so the browser can keep the event alive while the asynchronous operation runs.

The Service Workers specification matters because background sync depends on the service worker lifecycle: the work can run outside the original page that queued it. That is useful for resilient offline applications, but it also means a later network action may not happen at the same moment as the user's visible click.

Agent Context

For browser agents, Background Sync is a boundary between immediate action and deferred action. An agent may help compose a report, submit a support ticket, update a record, or queue a workflow while the user is offline. If the final network request fires later, the audit question becomes sharper: who authorized the queued work, what exactly was queued, and did the later context still permit it?

The safe pattern is to treat sync registration as a pending action, not as a completed action. If the queued work is high impact, the application should preserve a review or revalidation path rather than silently replaying an old intent after the facts have changed.

Governance Use

A governance-grade browser agent should keep deferred work legible. It should record the user-facing task, sync tag, origin, service worker version, queued payload class, expiration or retry policy, and whether the sync event actually ran. It should distinguish a draft saved locally, a queued request waiting for network, and a request sent to a server.

Background Sync also interacts with local storage governance. Queued work often sits in IndexedDB or another local store before the service worker sends it. That makes Storage Buckets API, AI Data Retention, and AI Audit Trails relevant to what looks like a performance feature.

Limits

Background Sync is not a general background scheduler, consent system, or guarantee that work will run at a precise time. It depends on browser support, service worker availability, network conditions, site engagement, power policy, and user or browser settings. MDN marks the API as limited availability, so production claims should name the browser, version, platform, and test date.

It is also not authorization. A request that was appropriate when queued may become inappropriate later. For money movement, account changes, worker discipline, legal filing, medical messaging, or irreversible publication, the system should ask whether deferred replay is acceptable and whether step-up confirmation is required.

Minimum Evidence Record

For agent-mediated background sync, record the origin, service worker script URL and version where available, sync tag, registration time, user-visible task, payload category, local queue location, retry and expiration policy, network send time, response status, agent task identifier, and any human confirmation. Do not log raw secrets, tokens, full message bodies, or unnecessary personal data merely to prove the queue existed.

Source Discipline

Use the WICG draft for the API shape, MDN for interface summaries and support warnings, and the W3C Service Workers specification for worker lifecycle claims. Do not confuse one-off Background Sync with Periodic Background Sync, push notifications, Background Fetch, or a native operating-system job scheduler.

Spiralist Reading

Spiralism reads Background Sync as the web learning to carry unfinished intentions across disconnection. That can be merciful: the form survives the train tunnel, the draft leaves when the network returns, the person does not have to repeat work.

The risk is that delayed action becomes invisible action. A humane agentic web must preserve the difference between wanting something now, queuing it for later, and actually doing it. The queue is a moral object because it holds a future act.

Sources

Return to Wiki