Your 24/7 Camera Is Not Recording Until Something Reads The Card Back

The weak point in a continuous-capture rig is not the lens or the app; it is a storage device that reports success for writes it never durably keeps. According to a dev.to writeup on running an old handset as a 24/7 camera, a worn or counterfeit flash card can accept a write, return success to the operating system, and not store the data ^[1].

Compare the failure you are used to. A dying hard drive is noisy about it: clicks, slowness, read errors, climbing SMART counters ^[2]. A card failing this way produces no signal at all. Free space goes down. The file appears in the listing with a plausible size and a plausible timestamp ^[3]. The recording app has nothing to report because, as far as the controller told it, the write landed ^[1]. The writeup's framing is the useful part: write success is not a durability signal, because every layer is only reporting on the promise made by the layer beneath it ^[4]. The gap surfaces when something reads the bytes back, which for a security recording tends to be the one day the footage matters ^[5].

The wear side is arithmetic, and it is worth doing before buying hardware. Consumer microSD cards are specified for a photography workload: bursts of writes, long idle periods, an occasional full-card format ^[6]. Continuous recording is the inverse. It is sustained, it is rewriting rather than accumulating (once full, the useful behaviour is delete-oldest-and-continue, which cycles the whole capacity), and it is unattended ^[7]. Buying a bigger card does not stop the rewriting; it only slows how often you go all the way around ^[8].

Bytes per hour is bitrate divided by eight ^[9]. At 16 Mbps, an ordinary handset default for 1080p rather than an extreme setting ^[11], that is about 7.2 GB per hour ^[12], so a 128 GB card is a full pass roughly every 17.8 hours ^[13], or about 1.35 passes per day ^[15]. The writeup puts the same card at around 123 full cycles a year at 4 Mbps, 246 at 8 Mbps, and 493 at 16 Mbps ^[10]. Two caveats it makes itself: real bitrate varies enormously with resolution, frame rate, codec and scene complexity, so measure an hour at your own settings and look at the file ^[16]; and full-capacity rewrites are not program/erase cycles per cell, because wear levelling spreads the writes around ^[17]. The point is not a death date but the order of magnitude: hundreds of full passes a year, which is not what the cheap card in the checkout aisle was priced against ^[18]. That is why high-endurance parts exist as a separate line and why the price gap is not purely branding ^[19].

The filesystem compounds it. Cards arrive as FAT32 or exFAT and phones keep them that way, because that is what makes the card readable in a laptop ^[20]. There are no per-block checksums, so nothing in the read path can tell the byte you wrote from a byte, and corruption stays silent ^[21]. FAT32 has no journaling, so a power loss during a metadata update can damage the allocation table itself, not just the recording in flight ^[22]. And the file-to-cluster mapping lives in one structure, so damage there can make physically intact files unreachable ^[23].

Two things to schedule. First, measure your actual bitrate over one recorded hour instead of trusting a spec sheet ^[16]. Second, put a periodic read-back in the deployment and pull real frames from old files. If read-back is the only event that separates a recording rig from an unmonitored one ^[5], then a rig without one is not in a good state or a bad state; it is in an unknown state. The related failure is worth knowing too: an interrupted recording can leave an MP4 that will not play at all ^[24].