Don't Be a Chocolate Teapot: How to Catch Windows Disk-Space Failures Before Your Endpoints Go Public

Last week, one of the busiest shopping streets in Europe got a live demo of what happens when nobody is watching disk space on a Windows 10 endpoint. A digital advertising screen on Oxford Street, supposedly looping a polished campaign for a chocolate caterpillar cake, stopped showing the chocolate and started showing its underwear to passing tourists: the raw Windows 10 machine underneath, error dialogs and all — reportedly because the thing had quietly run out of disk space. The Register's verdict writes itself in the headline: is this kit a chocolate caterpillar or a chocolate teapot? For the non-Brits, a chocolate teapot is something that looks exactly like the real thing but fails completely at its one job.

Funny story. Very unfunny operational reality. A full disk is the single most predictable failure in IT. It degrades slowly, it is measurable weeks in advance, and it is almost always preventable. Yet it still takes down print servers, WSUS boxes, database volumes, and apparently signage players in front of hundreds of thousands of pedestrians a day.

So here is the uncomfortable question for your Monday morning: how many Windows endpoints in your estate does nobody actually watch? Count them. Signage players, kiosk terminals, POS machines, meeting-room minis, factory-floor PCs, jump boxes, that one legacy app server with a 300GB boot drive. Deployed by someone else, owned by no one, invisible to monitoring that was only ever pointed at servers.

The Most Predictable Failure in IT Still Wins

Windows endpoints fill their disks in ways so consistent you could set a watch by them:

• The Windows Update cache (C:\Windows\SoftwareDistribution\Download) grows every patch cycle and only shrinks if something cleans it
• The WinSxS component store (C:\Windows\WinSxS) bloats a little more with every cumulative update
• Application logs that never rotate — a signage CMS endlessly caching content revisions, IIS logs on a forgotten web role, a print spooler on a busy file-and-print box, SQL Server transaction logs on a recovery model someone set in 2019 and forgot about
• Temp folders, browser caches on kiosk boxes, and volume shadow copies quietly eating 10-20% of the volume

And the reasons monitoring misses it are just as consistent:

1. The orphan endpoint category. Your server monitoring (Zabbix, Nagios, PRTG — pick your poison) covers servers. Your RMM (NinjaOne, ConnectWise, Datto) covers managed workstations. The signage player that marketing deployed with a local admin password nobody wrote down falls between the two: no agent at all, or an agent installed in 2022 with disk monitoring never switched on.

2. Windows' own low-disk warning has an audience of zero. The built-in low disk space notification is a balloon on the machine itself. On a signage player mounted behind a screen, nobody sees it — until the OS starts drawing the failure directly onto the big screen. Which is effectively what passers-by saw on Oxford Street: the failure mode became the content.

3. One static threshold cannot serve a whole estate. 10% free on a 2TB data volume is 200GB — pure alert noise. 10% on a 64GB kiosk SSD is 6.4GB and probably already too late, because endpoint-class devices tend to die from log loops eating 20GB an hour, not slow drift.

4. No trend data means you always find out too late. A threshold alert at 90% assumes slow, linear growth. Reality looks like: 84% on Monday, 97% on Wednesday, because the CMS started re-downloading its entire content library on a loop. Without growth-rate trending you learn about the problem at the worst possible moment.

5. The alert-to-action gap. Even when a disk alert exists, it lands in a console nobody has open or a mailbox nobody reads. The ticket only gets created when a human notices — an end user, or in this case, half of London.

What that costs, concretely:

• A full C: on the print server takes down company-wide printing at 9:01am on a Monday. Congratulations, you now have forty tickets that are all the same incident.
• A full disk on a WSUS server silently stalls patch compliance for an entire site for weeks. Nobody notices until the audit, or until the next vulnerability headline makes it obvious.
• A public-facing signage failure is a brand failure — this one made tech news. If an MSP runs that estate, it is a contract-risk conversation, not just a ticket.
• The standard incident path — alert sits somewhere, a human notices, ticket gets created, remote in, diagnose, clean up, verify — burns 60-120 minutes per incident, most of it waiting. And the tech handling it has 12 tabs open across 5 tools: RMM for the endpoint, a separate monitor for servers, the helpdesk for the ticket, a screen-share tool for access, and the email that started it all.

The root cause is not incompetence. It is legacy architecture. Monitoring, RMM, helpdesk and patching were built as separate products: separate agents, separate databases, no shared timeline. Answering a question as simple as 'which devices have a disk growth problem AND a patch backlog AND repeated user tickets?' requires a human with a spreadsheet. The tooling was never designed for the forgotten endpoint, and the process was never designed for prevention.

How AlertMonitor Closes the Gap

One agent, zero orphan endpoints. AlertMonitor's infrastructure monitoring covers servers, services, applications, scheduled tasks and Windows workstations in the same inventory and the same alert stream. A signage player on Oxford Street gets exactly the same disk policy as your SQL cluster. If it has the agent, it is monitored. There is no device class that falls between the cracks, because there are no cracks.

Disk monitoring done properly. Per-volume thresholds that combine a percentage with an absolute floor — warning at 80%, critical at 90%, plus a hard floor such as 'below 50GB' on large volumes so you don't drown in noise on 2TB drives. Then the part legacy tools skip: predictive trending. When C: on SIGNAGE-LDN-07 has been growing 1.5GB a day for two weeks, AlertMonitor tells you this volume is full in roughly nine days — today, not at 99.4%.

The right person, in seconds, not eventually. Intelligent alerting routes by device group, client and site — MSPs get client-scoped routing automatically — with escalation if nobody acknowledges within your SLA window. Deduplication and flap suppression mean one misbehaving volume pages you once, not eight times.

The alert becomes a ticket before a human is involved. The integrated helpdesk auto-creates the ticket from the alert with device, metric, threshold and trend attached. The response clock starts when the alert fires, not when someone notices — which also means SLA reporting finally comes from one dataset instead of being reconciled between two systems by hand.

Remediate from the same pane of glass. When the predictive alert fires, the tech pushes the cleanup runbook to the device with AlertMonitor's RMM remote execution, watches the output live, verifies free space, and closes the ticket. No VPN hop, no RDP juggling, no asking marketing for the signage player password.

Patching closes the loop. Patched endpoints download updates once and purge their caches on schedule. Patch compliance for those forgotten endpoints becomes visible instead of assumed.

The old way versus the AlertMonitor way, end to end:

• Old way: disk fills over three weeks. Windows shows a balloon nobody sees. The screen fails publicly. Marketing emails IT. Someone manually creates a ticket. Someone else remotes in, discovers zero bytes free, improvises a cleanup. Total: two hours, a furious marketing team, and a story on The Register.
• AlertMonitor way: the agent reports the baseline on day zero. The growth trend triggers a predictive alert and an automatic ticket at 'full in nine days.' The tech opens the ticket, pushes the cleanup runbook remotely in four minutes, frees 22GB, the verification metric confirms recovery, ticket closed the same afternoon. Marketing never knows. Tourists never know.

That is roughly two hours plus reputational damage compressed into fifteen minutes with zero drama. Across a 500-endpoint estate, catching even a dozen disk-fill incidents early per year recovers full days of technician time — and entire categories of tickets simply stop existing.

Practical Steps: Do This Today

1. Baseline the whole estate. Pull current disk space from everything with a heartbeat — servers and endpoints alike:

$servers = 'DC01', 'FILE01', 'SQL01', 'SIGNAGE-LDN-01', 'SIGNAGE-LDN-02'

Get-CimInstance -ComputerName $servers -ClassName Win32_LogicalDisk -Filter 'DriveType = 3' |
    Select-Object SystemName, DeviceID,
        @{n = 'SizeGB';  e = { [math]::Round($_.Size / 1GB, 1) }},
        @{n = 'FreeGB';  e = { [math]::Round($_.FreeSpace / 1GB, 1) }},
        @{n = 'FreePct'; e = { [math]::Round(($_.FreeSpace / $_.Size) * 100, 1) }} |
    Sort-Object FreePct |
    Format-Table SystemName, DeviceID, SizeGB, FreeGB, FreePct -AutoSize

Anything under 15% free goes straight onto the watch list. In an AlertMonitor estate this data is already in the platform — the one-liner is for auditing the machines you suspect have no agent at all.

2. Find out what is actually eating the space. The usual suspects, measured:

$paths = 'C:\Windows\Temp',
         'C:\Windows\Logs',
         'C:\Windows\SoftwareDistribution\Download',
         'C:\ProgramData\Temp'

foreach ($p in $paths) {
    if (Test-Path $p) {
        $sizeGB = [math]::Round(((Get-ChildItem $p -Recurse -File -Force -ErrorAction SilentlyContinue |
            Measure-Object Length -Sum).Sum) / 1GB, 2)
        '{0,-50} {1,8} GB' -f $p, $sizeGB
    }
}

And the big individual files, when the folders above do not explain it:

Get-ChildItem C:\ -Recurse -File -ErrorAction SilentlyContinue |
    Where-Object Length -gt 500MB |
    Sort-Object Length -Descending |
    Select-Object -First 10 FullName,
        @{n = 'SizeGB'; e = { [math]::Round($_.Length / 1GB, 2) }},
        LastWriteTime

3. Apply a standard cleanup runbook — the same one every time, pushed remotely. Purge the Windows Update cache safely:

Stop-Service -Name wuauserv, bits -Force

Remove-Item 'C:\Windows\SoftwareDistribution\Download\*' -Recurse -Force -ErrorAction SilentlyContinue

Start-Service -Name wuauserv, bits

Get-PSDrive C | Select-Object @{n = 'FreeGB'; e = { [math]::Round($_.Free / 1GB, 1) }}

Shrink the component store (elevated prompt, off-peak — it can run for a while):

Dism.exe /Online /Cleanup-Image /StartComponentCleanup

Cap shadow copy storage, which silently claims 10-20% of a volume by default:

vssadmin list shadowstorage
vssadmin resize shadowstorage /for=C: /on=C: /maxsize=10GB

In AlertMonitor these live as reusable remote execution jobs: launched in one click from the alert or the ticket, output streamed back, and the free-space metric re-checked automatically as verification.

4. Set thresholds that actually fit each volume. Percentage for small boot drives, absolute floor for large volumes: warn at 80% or below 40GB, critical at 90% or below 20GB. Apply the policy once at the device-group level, not machine by machine.

5. Turn on predictive trending for endpoint-class devices. Signage players, kiosks and anything running an application that caches content are your highest-risk disks. Trending turns 'disk will be full in 9 days' from a lucky guess into a standing alert rule.

6. Cover the forgotten endpoints deliberately. Run an inventory sweep: every Windows box that is neither a managed workstation nor a server. Then close the gaps with agents or network-level checks. For the Linux boxes hiding in the same racks:

df -h --output=source,size,used,avail,pcent,target | awk '$5+0 >= 90 {print}'

7. Close the loop with timestamps. Every disk alert auto-creates a ticket, remediation happens from the same console, verification is a metric rather than a vibes check, and the ticket closes with alert time, response time and resolution time attached. That is your SLA report — generated, not assembled.

A full disk should be a Tuesday afternoon ticket with a runbook attached. Never a public failure on a street walked by hundreds of thousands of people a day, and never a 2am page for something that was measurable three weeks earlier. A chocolate teapot looks exactly like the real thing and fails at its one job. Monitoring that only watches the servers you already think about is the IT equivalent. Watch the disks on every endpoint, alert on the trend, and keep the underwear where it belongs: off Oxford Street.

Related Resources

AlertMonitor Infrastructure & Server Monitoring AlertMonitor Platform Overview Book a Demo Infrastructure & Server Monitoring Resources