Storage
Who is using the space, per-user caps, and the nightly reconciler.
Storage in the console. Per-user usage, sorted by consumption, with each person's cap and a state of OK, Warning or Over cap.
Sort by any column, filter by minimum percentage used to find who is close, and page through.
What counts
Everything a member stores: collection documents, chat attachments, Workshop files, agent files, profile pictures, and derived data.
Derived is the one that surprises people, including administrators. Processing a document produces extracted text, page images for vision parsing and generated thumbnails, and those count against the quota. A collection can occupy noticeably more than the files uploaded to it, and vision parsing is the usual reason.
Storage is deduplicated across the organisation, so two people uploading the same file store the bytes once.
When somebody is over
At their cap, uploads are blocked. Nothing already stored is deleted, and they can still read everything.
Your options are to raise their cap or ask them to clear space. Before raising it, look at what they are storing: a single member well above everyone else is usually a collection with vision parsing on where it was not needed, which is worth fixing rather than funding.
Project storage
Resources owned by a project rather than a person are shown separately. This is the right home for anything a team depends on, because it does not count against an individual and does not leave when they do. See Projects.
Reconciliation reports
A nightly job reconciles what the database thinks is stored against what is actually in object storage. Each run reports orphans found and deleted, dangling references repaired, and bytes reclaimed.
You do not need to read these routinely. They are here for two moments: when a figure looks wrong and you want to know whether the accounting is trustworthy, and when a run fails, which is worth investigating because it means the two sides are drifting and the numbers on this page are slowly becoming fiction.