A restore that reports 0 objects restored can mean two completely different things: everything was already in place, or nothing was found because the path was wrong. Until now those looked identical — and the person reading them has usually just lost data.

Restores are now explicit about what happened.

• •The filenames, not just the count. Each restore keeps the list of files it actually wrote and shows it under the progress bar. It's stored with the run, so you can open a restore from last week and still see what it recovered. Large recoveries keep a capped sample, and the page says plainly when the list is a sample rather than the whole set.
• •"Nothing matched" is its own outcome. A restore that found no files under the folder you named now says so, names the scope it searched, and flags it — instead of a green tick and a zero.
• •A missing source fails loudly. If the directory being restored *from* doesn't exist or can't be read, the restore fails and names the path and host. An empty backup and an unreachable one are opposite answers and no longer look the same.
• •Live progress shows only what's being restored. The filename ticking past is a file being written, not one being checked and skipped — so a restore that recovers one file out of a thousand reads as exactly that.

Restores also run where they belong. They execute on background workers rather than the tier serving the app, so a large recovery no longer competes with the UI you're watching it from, and a deploy mid-restore doesn't interrupt it. Progress is shared across replicas, so the numbers advance smoothly instead of jumping backwards.