Disk-Space Sweeps: The Weekly Pass That Pays First

Thursday, 08:05, at Harbourview Clinic. Marion on reception has a queue of six patients and a scanner that has stopped scanning referral letters. The message on the screen says "unable to complete operation", which is accurate. Dev arrives from the desk at 08:20 and finds two hundred megabytes free on the reception PC's system drive. He finds the reason in under a minute: the scanning software has been saving every page at full resolution into a folder on the local disk since the day it was installed. Nobody told it to stop. He moves the folder to the share, empties the system's temporary files, and Marion is scanning again by 08:40. On the walk back he passes the three other reception PCs, each with the same scanner and the same software. He does not stop. He has a queue too.

Two of those three machines will produce the same ticket within the month, and Dev knows it, and the knowing is the uncomfortable part. A disk-space sweep is the scheduled read of free space on every machine on a list. It has a threshold that turns a number into a hit, a cleanup limited to what is safe to do uninvited, and a short notice to the user. It repeats weekly so that the next reception PC is found on a Friday morning rather than at five past eight with six patients waiting. This article is part of our Proactive Remediation series. Of the signals that series covers, this is the one to start with. That is because it has the longest lead time, the cheapest read, and the most recognisable ticket at the far end.

It starts with why disk space is the first sweep, then thresholds and why you need two kinds. Next come the sweep itself and the second pass that finds where the space went. After that: the cleanup that is safe, what to do when the space is the user's, and the machine that fills every month. Then come servers and shares, where the stakes change, and recording the sweep. It ends with a short war story and the sweep runbook to copy.

Why Disk Space Is the First Sweep

A full system drive breaks things that have nothing to do with storage, and that is why the tickets it produces are so hard to recognise. The system drive is the disk the operating system runs from. The operating system needs free space on it to do almost everything: install an update, write a log, load a user's profile, and print. It also needs space to open a large file or swap memory to disk when the machine is busy. When the space goes, the symptoms arrive as "updates keep failing", "my profile is temporary", "it froze during the report", "can't print" and "very slow". The technician who does not think to look at free space will spend twenty minutes on each before finding the one number that explains them all.

The lead time is weeks. Disks do not fill evenly; they fill the way a bath fills when someone has left the room, slowly and then all at once, but the slow part is long. A machine at ten percent free is usually two or three weeks from trouble, and that number is readable from across the network in under a second. No other signal on a small desk's list combines that much warning with that little effort to read, which is why Fixing Before the Ticket names it as the place to begin.

The fix is also mostly safe, and that matters more than the lead time. A disk-space hit usually has a cure that involves nothing of the user's: temporary files, caches, update leftovers. The technician can recover the space on a Friday morning without a conversation, which is not true of a failing battery or a certificate renewal. Where the cure does involve the user's files, the sweep still gives you two weeks to have the conversation calmly. Either way the ticket that would have arrived does not.

Thresholds: Two Numbers, Two Levels

A threshold is the free-space figure below which a machine counts as a hit. You need it in two forms at once, because neither works alone. A percentage threshold fails at both ends. Ten percent of a small system drive is a few gigabytes and an emergency. Ten percent of a large data volume is more space than the clinic uses in a year. A fixed figure in gigabytes fails the other way, treating a laptop with a tiny drive and a server with a huge one as the same problem. The working rule is "under so many gigabytes or under so many percent, whichever comes first", with different numbers for different kinds of machine.

You also need two levels. The watch level is where a machine appears on the report and gets a look. The act level is where it gets a ticket and a cleanup that week. The gap between them stops the sweep from producing a ticket for every laptop that happens to sit at eleven percent. It lets you see a machine falling across three consecutive reports. That tells you how fast it is filling, which tells you how long you have. A machine that drops from watch to act in one week is a different problem from one that has sat at the watch level for a quarter.

The table below is a starting point from a fictional desk, not a standard. Tune it to your fleet after a month of reports, and expect the laptop numbers to move most. The numbers are only there so you do not start from a blank page.

Notice the last row. A volume that can fill in a night has a lead time shorter than a weekly sweep, and belongs to monitoring, which the first article in this series draws the line around. The sweep covers the rows above it, and especially the first two, which are the machines monitoring almost never reaches.

The Sweep, and the Second Pass

The first pass is the read-only script from the first article, run against the machine list, producing a line per machine with free gigabytes and free percent. Sort it, mark the watch and act levels, and you have the week's work on one page. The whole first pass against sixty machines takes a few minutes to run and ten to read. The second pass is where the time goes. It is the question "where did the space go?", asked of each machine at the act level before anything is deleted.

The second pass is also read-only, and it is also short. It lists the size of each top-level folder on the system drive. Then it lists the size of each folder under the usual suspects: the users' folders, the system's temporary area, the update cache, the application data folders. Here it is in plain words; the real one, in the shell or scripting language built into the operating system, is a handful of lines and changes nothing.

WHERE DID THE SPACE GO? (reads only; changes nothing)
for each folder at the top of the system drive
    size = total size of everything under folder
    write "folder, size in GB" to space-report.txt
for each user folder under the users area
    size = total size of everything under it
    write "user folder, size in GB" to space-report.txt
sort space-report.txt by size, largest first
print the ten largest lines

Ten lines tell you which of three stories you are in. If the space is in the system's own areas, temporary files, update leftovers and caches, the safe cleanup will recover it and the ticket closes on Friday. If the space is in a user's folder, the ticket becomes a notice and a conversation, and the cleanup waits. If the space is in an application's data folder, you have probably found a machine that will fill again. The ticket should say so in its first line, because that is the one that needs a cause rather than a cleanup. Read the ten lines before touching anything. Every disk-space mistake I have made or watched started with a technician who skipped them.

The Cleanup That Is Safe

The safe cleanup is the short list of things the operating system or the desk created and the user never did. Write it down in the runbook. Then "safe" means the same thing on a Friday with a trainee as it does with the desk lead. Temporary files the system created for itself. Temporary files applications created and abandoned. Leftovers from installed updates, which the system's own cleanup tool knows how to remove and you should let it. Log files older than the desk's retention rule. Installers the desk itself staged for an earlier job. The recycle bin, once the user has been told and has had a day. Every operating system I have used ships a cleanup tool for most of these. None of them puts it anywhere a receptionist would look. So the sweep technician is usually the first person to run it on that machine.

Browser and application caches sit on the edge of the list and deserve a sentence of their own. They are safe in the sense that nothing is lost; they are unsafe in the sense that the user may notice. I once recovered eighteen gigabytes from a laptop by emptying a cache. I spent the afternoon on the phone explaining why a web application had signed the user out of everything and forgotten their preferences. The cache was safe. The surprise was not. Clear caches when the space is needed, tell the user in the notice what they will see, and never clear one on a machine that is mid-task.

Never delete anything you could not describe in one plain sentence to the person who owns the machine. Not "some old files". The sentence. That rule removes the entire unsafe list without needing to write it. It covers anything in the user's own folders, including the Downloads folder, the desktop and the pictures folder. It also covers mail data files. Anything inside an application's data folder is on the list unless that application's documentation says the folder is a cache. So is anything with a name you do not recognise. The user's files are the user's. The desk's job on a Friday is to recover the system's space and to tell the user, clearly and kindly, where the rest of it is.

When the Space Is the User's

Half the hits on a laptop sweep end in a user's folder, and the right response is a message, not a deletion. The message says what the sweep found and where the space is in plain terms ("about forty gigabytes of video in your Documents folder"). It says what the desk has already recovered and what the user can do, with the easiest option first. They can move it to the share, archive it, or tell the desk it needs to stay and the machine needs a bigger drive. The message gives them a week and says the desk will check again. The notice is a template, and Telling Users Before They Notice is the article that writes it; the disk-space version differs only in naming a folder and a size.

Make the conversation about the machine, never about the files. "Your laptop is running out of space and here is where it has gone" lands as help. "You have forty gigabytes of video on a work laptop" lands as an inspection, even when the video is the training course they were asked to produce. The sweep technician is not the owner of the content and does not need an opinion about it. They need the space back, or a ticket for a bigger drive, and either is fine.

Follow up when the week is out. Most users move the files when asked, some forget, and a few genuinely need the space. The follow-up is a second message and then, if the machine is still at the act level, a short call. A desk that sends the notice and never checks has told the user the problem is theirs now, which was not the intention and will not be how it is remembered.

The Machine That Fills Every Month

Some machines come back. The sweep cleans a shared PC in week one. It is at the act level again in week five, and in week nine. By then everyone on the desk knows its name. The machine that fills every month has one of three problems: a leak, a habit, or a drive the size of a postage stamp. A leak is software writing files it never removes, usually logs, exports or scan output. The second pass finds it in the application's data folder growing by the same amount each week. A habit is a user, or a job, saving to the local disk because that was the default. A small drive is a machine that was bought for a job it no longer does. Each has its own fix, and none of the fixes is "clean it again".

The ticket history is how you know which machine this is, and this is where keeping the device's name on every ticket pays off. A desk that records which machine each sweep ticket was about can search for the name and see three cleanups in a quarter. A desk that recorded "reception PC" on each will not. Most small desks have no asset system and do not need one for this. Linking Devices Without an Asset System covers how a field on the form carries the machine's name well enough to make the search work.

The third visit is the moment to stop cleaning and start looking for the cause. Leaks are fixed by telling the software to keep less. Most applications that write logs or output have a retention or location setting. Pointing the output at the share or capping the logs ends the problem permanently. Habits are fixed by changing the default save location and telling the user why. Small drives are fixed by a bigger drive, and the sweep report is the evidence for the purchase. That is because "this machine has needed a cleanup every five weeks for a quarter" is a sentence a budget holder can act on. Any of the three, once done, removes a ticket type from the fleet rather than from one machine, and that is the moment a sweep turns into maintenance.

Servers and Shares: Same Sweep, Different Stakes

The same read-only script works against servers, and the stakes change at the act level. A laptop that fills inconveniences one person. A server system drive that fills stops services for everyone who uses them, and a file server data volume that fills stops the whole building from saving. The sweep is therefore worth running against servers even where monitoring already watches them, as a second pair of eyes with a longer view. The report should put servers at the top regardless of their numbers.

What changes is who acts. The sweep technician does not clean a server on a Friday morning because the report said so. A server system drive at the act level is a change: it gets a ticket, a time, a rollback and a name. The server's owner does it or approves it, however light the desk's change record is. A file server data volume at the act level is not the desk's to clean at all. The space belongs to the departments whose folders are on it. The desk's role is to report the ten largest folders to their owners and to ask the owners what to do. A quota, which is a limit on how much a folder or a user may hold, is the real fix for a data volume that fills. It is a decision for the data owners rather than a cleanup for the desk.

Shared mailboxes and personal mail stores belong in the same category as data volumes. The sweep may read the size; the desk never deletes a message. The notice goes to the mailbox owner with the size and the biggest folders. The fix is an archive, a retention rule or a bigger quota, decided by someone who owns the content. I say this plainly because the first instinct of a tired technician on a full mail store is to empty the deleted items folder. The deleted items folder is where a surprising number of people file things.

Recording the Sweep

Every sweep gets one ticket for the pass and one ticket per hit, and both carry numbers. The pass ticket says how many machines were on the list, how many answered, how many were at watch and at act, and has the report attached. The hit tickets each say which machine, what free space was found, what the ten largest folders were, what was cleaned, and what the free space was afterwards. Before and after, in gigabytes, on every hit ticket, is the one habit that makes the measuring article possible. Without the two numbers the sweep's work is a feeling.

Keep the technician's working and the user's message apart on the same ticket. The folder sizes, the cleanup steps and the before-and-after figures are the desk's record; the user gets the short notice and nothing else. If you run QuerySolv, that split is the ordinary one between an internal note and a public reply. The working then stays with the desk and the user sees only the message meant for them. In any tool, the test is that a user reading their ticket sees a helpful note, and a technician reading it a year later sees exactly what was done.

Close the hit ticket when the machine is above the watch level, not when the cleanup is done. A cleanup that recovered four gigabytes on a machine that needed twenty has not finished. Where the space is the user's and the notice has gone, the ticket stays open for the week and closes on the follow-up. Where the machine is a repeat, the ticket says so in its first line and links to the earlier ones. Then whoever picks up the fourth visit sees the three before it without searching. The script of the cleanup itself needs checks and stop conditions to make it safe to hand to a trainee. That is the business of Turning a Fix Into a Script Safely. The runbook below is the hand-run version it would start from.

A Short War Story: The Label Printer at Tollgate Foods

Tollgate Foods ran its loading bay from one dispatch PC that printed the delivery labels for every pallet. Once every five weeks or so, at about half past six in the morning, the PC stopped printing and the lorries stopped leaving. The first three times, a technician drove out, found the system drive full, deleted what looked safe, restarted the label software, and left. Each visit cost about forty minutes. During that time, six to eight lorries waited with their engines running and the transport manager stood behind the technician's chair. On the fourth visit, Ania ran a ten-line folder listing before touching anything. She found that the label software kept a log file for every label it had ever printed. Those files sat in a folder that had reached ninety gigabytes. The software had a retention setting in its own configuration screen that nobody had opened. She set it to thirty days, pointed the output at the share, and the machine has not filled since. The review put the cost of the four mornings at roughly twenty lorry-hours and a transport manager's patience. The lesson Ania wrote on the ticket was shorter: the third visit is when you look for the cause, and the first visit is when you should have.

The Sweep Runbook

The runbook below follows the runbook article in this library. The runbook sets out what it assumes, numbered actions with their checks, what good looks like, when to stop, and when it was last run. It is written for a competent stranger on the rota who has never done the sweep before. It assumes the first-pass script and the folder-listing script exist and are named. Fill in the thresholds from your own table, put the share path and the ticket conventions in, and keep it to the page.

DISK-SPACE SWEEP — WEEKLY RUNBOOK
Runbook RB-____   Owner (role): sweep technician on the rota   Visible to: agents only
Runs: weekly, ________ at ____:____   Machine list: machines.txt (owner: ________)

APPLIES WHEN
  It is the scheduled sweep day, or a disk-space ticket has arrived from a
  listed machine between sweeps (run the second pass on that machine only).
YOU NEED
  Admin rights on the listed machines; the first-pass script; the folder-listing
  script; this week's pass ticket, opened before step 1.
THRESHOLDS (from the desk's table)
  Laptops and desktops: watch under ____ GB or ____ %; act under ____ GB or ____ %
  Shared PCs:           watch under ____ GB or ____ %; act under ____ GB or ____ %
  Servers:              report only; hand to the server owner as a change

STEPS
  1. Run the first-pass script against machines.txt.
     Expect: one line per machine in sweep-report.csv; offline machines marked.
  2. Attach the report to the pass ticket. Record: machines listed ____,
     answered ____, at watch ____, at act ____, offline ____.
  3. For each machine at the act level, open a hit ticket named for the machine.
     First line: "found by sweep; user not yet affected" or "repeat: see ______".
  4. On each act machine, run the folder-listing script.
     Expect: the ten largest folders. Paste them into the hit ticket's internal note.
  5. Decide which story the ten lines tell:
     a. space in system areas  -> step 6
     b. space in a user folder -> step 8
     c. space in an application's data folder -> step 9
  6. Run the safe cleanup: system temporary files, abandoned application
     temporary files, update leftovers (the system's own cleanup tool), logs past
     retention, desk-staged installers. Do not touch user folders.
     Expect: free space above the watch level. Record before ____ GB, after ____ GB.
  7. If still below the watch level after step 6, treat as 5b or 5c.
  8. Send the user notice (folder, size, what was recovered, options, one week).
     Set a follow-up for seven days. Do not delete anything in the user's folders.
  9. Record the folder and the weekly growth in the hit ticket. Find the setting
     that controls the output or the log retention. Raise the fix as a change if
     the machine is shared; otherwise apply it and record the before and after.
 10. For machines offline two sweeps running, note the name on the pass ticket
     for the machine-list owner to check.

EXPECTED TIME
  First pass and reading: 15 minutes. Each act machine: 10 to 20 minutes.
  If the whole sweep exceeds 90 minutes, raise the act threshold or shorten the list.

STOP AND ESCALATE
  Any server at the act level: do not clean; hand to the server owner as a change.
  Any machine at the act level for the third time: stop cleaning; raise a cause
  ticket and link the earlier three.
  Anything you cannot describe in one plain sentence to the machine's owner: leave it.

LAST RUN
  Date: ________  By: ________  Pass ticket: ________
  Differences noted and fixed in this runbook: ______________________________

Dev's three reception PCs went onto the clinic's first sweep the following Friday. Two were at the act level, both with a scan folder on the local disk. Both were fixed before Monday's clinic with the output pointed at the share and a line added to the scanner setup notes. Marion got a two-line message about hers and replied "thank you, I had no idea", which is the correct response to a problem that never happened. The clinic's desk now runs the sweep every Friday at ten. It has not had a "scanner cannot save" ticket since, and the pass ticket says so, every week, in numbers.

Frequently Asked Questions