When Will My Hard Drive Fill? — the alarm clock for your recording drive

Every long recording session has the same hidden question: not "how many hours fit," but "what time does this drive die?" If you start at 8 p.m. and the drive hits 90 percent at 3:42 a.m., you need to know that before you fall asleep — not discover it from a corrupted file in the morning. This tool turns free space and bitrate into a wall-clock time. It gives you the exact hour and minute your recording drive crosses 90 percent (the safe stopping point) and 100 percent (the failure point), plus a live timeline that updates as the clock runs.

What the fill clock actually tells you

Two timestamps, one bar. The 90 percent mark is the headline because it is the moment to act: above it, filesystems slow down, operating systems start fighting for space, and OBS encoders begin dropping frames on the writes that matter most. The 100 percent mark is shown only so you can see how thin the margin really is — usually a couple of hours past the point where you should already have stopped.

The timeline underneath is not decoration. It shows you, proportionally, how much of the session happens before pressure starts. A stream that runs eight hours but hits 90 percent at hour six has two hours of danger time; knowing that shape in advance is what lets you schedule a drive swap instead of improvising one.

Because the clock re-evaluates every second from your current time, you can leave the tab open during the session. If you pause recording, the fill estimate stops being accurate (it assumes continuous writing), so treat the page as a pre-flight and mid-session check, not a live byte counter.

The math behind the clock

One line drives everything: hours-to-90% = (free GB × 0.9) ÷ GB per hour, where GB per hour = total Mbps × 0.45.

The 0.45 comes straight from unit conversion: one megabit per second sustained for one hour is 3.6 billion bits, which is 450 million bytes, which is 0.45 decimal gigabytes. Total Mbps is your video bitrate plus audio bitrate times track count. Then the tool adds that duration to your start time and hands you a clock reading.

Two numbers people trip over: free space is what the OS reports right now (Finder, Explorer, or df -h), not the drive's labeled size — and decimal GB is used throughout because that is what drives are sold in and what the vault bills in. Mixing in binary GiB would make the clock run about seven percent long, which is exactly the wrong direction for an alarm.

Three sessions on the clock — hypothetical, labeled

Note for hard-drive-fill-calculator: The three scenarios below are hypothetical examples (illustrative, not sourced case studies) for this specific tool — realistic schedules run through the fill math, not measurements from named machines.

Scenario 1 — the overnight charity stream. Start Saturday 8 p.m., 250 GB free, 1080p60 gaming at 12 Mbps plus two 160 kbps audio tracks. Draw is 12.32 Mbps, or 5.54 GB per hour. The 90-percent line sits at 225 GB (0.9 × 250), and the 5.54 GB/h draw consumes it in 40.6 hours. The clock says: 90 percent lands around 12:30 p.m. on Monday. Nobody is watching a charity stream at that hour expecting disk drama — the crew sets an alarm for Monday morning, swaps to a fresh drive on the hour-36 break, and the wall never arrives on screen.

Scenario 2 — the wedding-adjacent two-day shoot. Start Friday 9 a.m., 500 GB free on the shoot SSD, two cameras recorded as 1080p30 at 8 Mbps each plus 192 kbps audio. Total draw 16.19 Mbps, 7.29 GB per hour. Ninety percent (450 GB) lands after 61.7 hours — comfortably past the weekend. But the 100 percent mark is only 6.8 hours later, which tells the operator the real plan: offload each night, because if Saturday runs long into overtime coverage, Sunday morning starts with a near-full drive. The clock's job here is showing that "it fits" and "it fits with margin" are different answers.

Scenario 3 — the weekday podcast block. Start 7 p.m., 40 GB free on the laptop, 1080p30 talking head at 4 Mbps, one 160 kbps track. Draw 4.16 Mbps, 1.87 GB per hour. Ninety percent of 40 GB is 36 GB: 19.2 hours of recording. Two hours of episodes tonight uses 3.7 GB. The clock says you are safe for nine more sessions like this one — the number that stops you from buying a drive you do not need yet, and tells you roughly which week you will.

What actually happens when a drive fills mid-recording

This is the failure mode the clock exists to prevent, and it is uglier than "recording stops."

MP4 containers lose everything unindexed. OBS writes the moov index at Stop. If the disk fills and the write dies, the file can sit at full size with no way in — recovery then needs a reference file and an index-rebuild tool. The footage is usually still there; getting to it is a project.

MKV loses the last cluster only. Matroska writes its index as it goes, so a disk-full crash typically costs the final seconds in the write buffer. Everything before that stays playable after a one-line remux. This is one more reason the recording format should be MKV or fragmented MP4 for any session that might outlast the drive.

The OS makes it worse. Near-full filesystems allocate slowly and fragment aggressively, so the last hour of recording is also the hour most likely to drop frames even before the write fails outright. On macOS the problem hides further: Finder counts iCloud purgeable space as available until the system needs it, so the free-space number you type into this tool can be optimistic by gigabytes.

Fragmented MP4 splits the difference. Each fragment carries its own headers, so a mid-write death costs one fragment — a few seconds — and the rest plays. If your workflow can tolerate it, fMP4 is the most disk-full-tolerant container OBS ships.

Operational playbook — living with the clock

Set the alarm for 90 percent minus one hour. The fill time is a prediction assuming continuous recording; any pause shifts it later, any bitrate spike shifts it earlier. An alarm an hour before the predicted mark gives you a calm window to finish a segment and swap drives.

Pre-stage the next drive. If the clock says you will cross 90 percent during the session, the replacement drive should already be formatted (exFAT or APFS/NTFS, never FAT32), plugged in, and tested with a ten-second write before you need it at 3 a.m.

Rotate at segment boundaries. Swapping drives mid-scene loses the shot's continuity; swapping between segments or rounds loses nothing. Plan the swap into the schedule the same way you plan breaks.

Re-run the clock after every archive. Deleting old footage changes the start point. The calculator's answer is only as good as the free-space number you typed, and free space is the field that goes stale fastest.

Edge cases the clock can misread

Variable bitrate days. CQP encoders average near their nominal rate over time, but a session full of confetti, fireworks, or fast panning can run 20–40 percent hot. If your content is spiky, feed the clock a bitrate 20 percent higher than nominal and treat the result as the honest estimate.

Other writers on the drive. The math assumes the recorder is the only thing filling the disk. A Time Machine local snapshot, a game installing an update, or an editor rendering on the same volume all subtract from your real runway. Dedicated recording drives exist for exactly this reason.

Drive sleep and spin-down. Some external enclosures park after idle minutes; waking them mid-write can drop the first frames after a pause. Keep the drive awake during long sessions (caffeinate on macOS, power settings on Windows) so the clock's continuous-write assumption holds.

Daylight saving and timezone shifts. The clock adds hours to a wall time. A session crossing a DST boundary at 2 a.m. lands an hour off the naive expectation — not the tool's fault, but worth knowing when you set the alarm.

Why wall-clock beats hours for real schedules

A duration answer — "you have 41 hours of recording" — is a number you must still translate into your life. A clock answer — "the drive dies Monday 12:34 p.m." — is already a decision. The translation step is where mistakes happen, because humans do not schedule in elapsed hours; they schedule around sleep, work blocks, and other people.

Three concrete habits follow from reading the clock instead of the duration:

Alarms belong on the calendar, not in your head. If the 90 percent mark lands while you will be asleep, create the alarm at session start, not when you feel tired. The fill clock is deterministic — same inputs, same answer — so there is no reason to defer. Set it an hour before the predicted mark, because the prediction assumes continuous recording and real sessions have gaps.

Handoffs need a timestamp, not a ratio. "The drive is two-thirds full" tells a co-host nothing. "The drive crosses 90 percent at 6:15 a.m., swap it during the breakfast break" survives a handoff intact. When more than one person touches a long recording, paste the clock output into the session doc verbatim.

Multi-day events should be planned day by day. A 48-hour subathon is not one 48-hour prediction; it is two predictions with an overnight recheck between them. Bitrate variance, surprise guests, and OS updates all nudge the real fill time, and each morning recheck costs ten seconds. The further out a prediction reaches, the more it becomes a plan to verify rather than a fact to trust.

Drive hardware behaviors that move the clock

The fill clock assumes a constant write rate meets a constant capacity. Real drives break both assumptions in ways worth knowing before a long session.

SMR drives slow to a crawl as they fill. Many affordable external drives use shingled magnetic recording, which writes in overlapping bands. Sustained recording into an SMR drive eventually exhausts its fast cache zone, and throughput can collapse from 100+ MB/s to single digits until the drive reshuffles data. The symptoms look like encoder trouble — dropped frames, stalled writes — but the stats dock shows the encoder is fine while the disk is choking. If your drive is SMR (most 2.5-inch externals above 1 TB are), keep the fill target conservative and prefer shorter sessions with offloads between them. CMR drives do not exhibit the cliff and are the better purchase for dedicated recording duty.

External SSDs throttle thermally on sustained writes. A fast NVMe in a compact enclosure can write at full speed for minutes, then shed 30–50 percent of its throughput as it heats up. The fill clock does not move — the same bytes still arrive — but if the throttling dips below the encoder's output rate even briefly, OBS drops frames. Enclosures with metal shells and a little airflow handle multi-hour sessions far better than pocket-sized plastic ones.

USB power management can suspend a drive mid-session. Both Windows and macOS will park idle USB devices to save power, and "idle" detection can misfire during steady low-bandwidth writes on some enclosures. A suspended drive returns as a new device or not at all, and the recording file ends at the suspension point. Disable USB selective suspend for the recording drive on Windows, and on macOS use a powered hub for bus-powered drives during long sessions.

The enclosure interface is a hard ceiling. A USB 2.0 port caps at about 35 MB/s real-world — plenty for a 6 Mbps recording, but a dual-canvas 4K session at 50+ Mbps combined with filesystem overhead gets uncomfortably close. Check that the port's rated throughput is at least five times the recording rate before trusting a multi-hour clock on that port.

Weekly planning with the fill clock — a worked schedule

Note for hard-drive-fill-calculator: The schedule below is a hypothetical example (illustrative, not sourced case studies) showing how the clock feeds a weekly plan.

A podcast studio records three 90-minute episodes weekly at 1080p30, 6 Mbps video plus 160 kbps audio — 2.77 GB per hour, about 4.2 GB per episode, roughly 12.5 GB per week. On a 1 TB dedicated drive with a 50 GB reserve, the clock says: about 324 hours to 90 percent, which sounds like forever.

The useful planning number is smaller. Their editor takes four days to process an episode, so finished footage is not deleted until day five. Steady-state occupancy is about 62 GB (five days of episodes in flight), plus 30 GB of rolling scratch for renders. The drive never approaches 90 percent — but the clock still earns its keep on the exception week: a client adds a two-day video workshop (16 hours of recording, 44 GB) to the normal schedule. Re-running the clock with the combined plan shows occupancy peaking around 170 GB, still comfortable, but only because they checked before committing to the workshop on the same drive.

The pattern generalizes: the fill clock is not only for the drive that is about to fill. Running it against your busiest realistic week — not your average week — is what tells you whether your drive rotation policy has a hole in it. Average weeks never fail; busy weeks always do.

Troubleshooting the clock itself

The clock says hours, but the drive filled faster in real life. Something else wrote to the drive: OS updates, Time Machine local snapshots, editor caches, or a second recorder pointed at the same volume. Check what else mounted there before the session and give the recorder exclusive use of the disk.

The clock says the drive fills at 2 a.m. but it filled at midnight. Your real bitrate exceeded the nominal setting. CQP recordings run hot on complex scenes, and "6 Mbps" VBR encoders routinely average 7–8 on busy content. Re-run with the measured average from your last session's file (size in GB ÷ hours ÷ 0.45) rather than the configured number.

Free space keeps shrinking while recording is paused. Background writers again — Spotlight indexing, antivirus scans, cloud sync clients materializing files. A dedicated recording drive with those services excluded keeps the clock honest.

Two different drives, same inputs, different times. The clock output is deterministic; the inputs are not. One of the two free-space readings is counting reserved or purgeable space the other excludes. Re-read both from a terminal (df -h on macOS/Linux, drive properties on Windows) and enter the conservative figure.

How this connects to WeaverClip — without bullshit

The fill clock exists because footage accumulates locally until a human intervenes. WeaverClip removes the accumulation: the macOS helper streams each minute of recording to the vault as the next minute is captured, and releases the local copy only after the vault confirms every byte. Local storage becomes a rolling buffer of minutes rather than a growing liability of hours, and the wall-clock alarm this tool computes stops approaching at all. The calculator stays the right instrument for choosing bitrates, sizing sessions, and planning drive rotation — but record through the verified path and the only clock you watch is the one on the wall.

FAQ

Why does the tool care about 90 percent at all? Because that is where reliability ends, not where space ends. Filesystems, swap, and encoders all degrade in the last stretch; stopping at 90 costs you ten percent of capacity and buys back nearly all of your safety.

Can I trust the clock past 24 hours? The math scales fine to days, but long predictions compound two errors: CQP bitrate variance and other processes touching the drive. Beyond a day out, treat the answer as a planning estimate and re-check each morning.

What free-space number should I enter? The conservative one: what your OS reports as available minus anything purgeable or reserved. On macOS, df -h in Terminal is more honest than Finder's summary.

Does the clock include audio? Yes — video Mbps plus audio Mbps times track count. Six audio tracks at 160 kbps add almost a full megabit per second, which over a two-day event is over 40 GB the video-only number would have missed.

What if I record two canvases? Double the video bitrate before entering it. Two 6 Mbps canvases is 12 Mbps of video; the tool will then show you the real clock instead of a comfortable fiction.

Will a slower drive fill at the same time? Fill time depends on bitrate, not drive speed — but a slow drive can fail before it fills, dropping frames or stalling writes. If your drive cannot sustain the encode rate, the clock is optimistic; check the Stats dock for skipped frames. Should I stop recording exactly at 90 percent? A little earlier if you can choose the moment cleanly — end at a segment boundary, a round, or a scene break. The threshold protects the file; stopping at a natural break protects the content.

Does the clock account for filesystem overhead? It uses decimal GB end to end, which already matches how filesystems report free space. The small metadata overhead (typically 1–2 percent) is absorbed by the reserve and the 90 percent rule together.

Can I chain multiple drives automatically? OBS does not rotate drives for you; a human or a script must switch the recording path. The clock's job is to tell you exactly when that switch must happen, so you can script or schedule it rather than improvise it.

What if I record to two drives simultaneously for redundancy? Run the clock twice with each drive's own free space and treat the earlier result as the binding one. Redundant recording doubles the write load — check that both enclosures sustain it, per the hardware section above.

Appendix — fill clocks for common setups

A quick lookup of hours-to-90% at typical recording rates, so you can sanity-check the tool without running it:

1. 100 GB free at 2.77 GB/h (1080p30 podcast) — 32.5 hours to 90 percent
2. 250 GB free at 5.54 GB/h (1080p60 gaming + 2 tracks) — 40.6 hours to 90 percent
3. 500 GB free at 7.29 GB/h (dual-camera 1080p30) — 61.7 hours to 90 percent
4. 1 TB free at 8.10 GB/h (1440p60 gaming) — 111 hours to 90 percent
5. 2 TB free at 11.25 GB/h (4K30 balanced) — 160 hours to 90 percent

The pattern worth memorizing: every extra megabit per second costs 0.45 GB per hour. A 2 Mbps bump on a 40-hour event is 36 extra gigabytes — often the difference between one drive and two. That single line of arithmetic is the whole tool; the clock just turns it into a time you can put an alarm on.