Service Worker Lifecycle Debugger
Why is your new service worker stuck in "waiting"? This debugger shows the installing, waiting, and active workers in real time, logs every state transition, and lets you trigger updates — no DevTools required.
Tool interface
Inspecting origin:
"SKIP_WAITING" posts a message to the waiting worker. It only takes effect if your
service worker listens for it and calls self.skipWaiting().
Registration
- Scope
- updateViaCache
- Controller
Lifecycle slots
Event log
Introduction
Service worker updates are deliberately conservative — a new worker waits until all tabs using the old one are closed. That's powerful but confusing when you're trying to ship a fix. This debugger makes the lifecycle visible so you can see exactly where a worker is stuck.
How it works
- Reads the registration via
navigator.serviceWorker.getRegistration(). - Shows installing / waiting / active workers with their states and scripts.
- Listens to
statechange,updatefound, andcontrollerchange. - Offers
registration.update()and a SKIP_WAITING message.
Privacy
All observation is local via the Service Worker API. No data leaves the origin. No account, no API key.
Limitations
- Cannot inspect service worker internals or code execution.
- SKIP_WAITING only works if the worker listens for the message.
- Requires a secure context (HTTPS or localhost).
FAQ
Why is my new worker stuck in "waiting"?
A new worker waits until all tabs using the old worker close. Call self.skipWaiting() in the worker's install event to activate immediately.
Is my data uploaded?
No. Everything is observed locally in your browser.