WorkManager

Background work is the hardest thing to debug from the outside, because by the time someone notices it did not happen there is nothing on screen to look at. This panel lists every persisted work spec WorkManager knows about, with the state and the constraints that explain why it is sitting there.

What is listed

Every persisted work spec — one-time, periodic, expedited, chained and unique work — from your app and from any library that schedules work. That second part is often the surprise: an analytics or sync SDK you never think about shows up here too, which is exactly what you want when something is draining battery or firing at the wrong time.

Each row carries a colour-coded status badge, so a queue full of ENQUEUED or a repeated FAILED is visible without opening anything.

What a work spec shows

Identity

Worker class name, work id, unique work name, and tags.

State and attempts

Current state, run attempt count, backoff policy, and the last stop reason on WorkManager 2.9 and newer — the field that finally tells you the OS cancelled your job rather than your code failing.

Constraints

Network type, charging, device idle, battery-not-low and storage-not-low. A job that never runs is usually a constraint that is never satisfied, and this is where you see which one.

Data

Input, output and progress payloads — what was handed to the worker and what it handed back.

Scheduling

Periodic and expedited indicators with the repeat interval and flex window, schedule metadata, and the completed period count for periodic work.

A payload too large to read comfortably in place opens in the value viewer, like any other oversized value in the inspector.

Finding one job

Search matches worker class, work id, state, tag and unique work name. On an app with a lot of scheduled work, searching by tag is usually the fastest way in — assuming you tagged it, which this panel will quickly convince you to start doing.

Inspection is read only

You cannot cancel, enqueue or retry work from here. That is deliberate: mutating a live queue from a debug tool changes the very behaviour you are trying to observe, and a cancelled unique job can leave your app in a state it would never reach on its own.

To make work run on demand, add a debug trigger in your own app and watch the result in this panel.