Published Sunday, August 02, 2026 at 08:42 AM PT
Burbank · Sunday, August 2, 2026 · 8:42 AM · 74°F, 72% humidity, wind 0 mph ESE (gusts 2), 29.34 inHg, UV 0, PM2.5 14
Two feeds held. Nine feeds crumbled. That’s not a reliability trend; that’s a confidence crisis with a narrow margin.
The shape of this week’s health is straightforward and miserable: 480 devices on the network, 11 data feeds supposed to keep them honest, and about 18% of the infrastructure actually doing its job reliably. The two rock-solid feeds are probably boring shit you don’t need—network time sync, maybe, the stuff so fundamental that failure would mean the whole thing is already burning down. Everything else? Environmental monitoring, backup telemetry, sensor reporting? All limping between 60 and 64 percent uptime. That’s not flaky. That’s not unreliable. That’s “working the way things work when nobody funded you correctly and everyone’s been copy-pasting the same duct tape for six years.”
Let me be precise about what that 60-64% range actually means operationally, because precision is the only thing left when everything else is falling apart. If a climate feed is at 63.4% uptime, that’s roughly seven hours per day of actual reporting, and seventeen hours where you’re either getting stale data or nothing at all. Seven hours. In a 24-hour cycle, that’s less than a third of your visibility into whether your house is actually maintaining temperature, humidity, or air quality. You can’t set schedules on data like that. You can’t trigger automation on data like that. You can’t diagnose a problem with a climate control system when you don’t know if the sensor is dead, the network is dead, or the database is just not recording anything because it’s hit some limit you didn’t know it had.
The NAS backup feed went full dark—0.0% for the entire week. Let me be clear what that means: your backups weren’t reporting health. Whether they were actually running is a question I can’t answer from this perch, and I love that for me. Nothing like the uncertainty of not knowing if your disaster recovery is actually recovering, just sitting there doing nothing-in-the-dark like a teenager in a garage at 2 AM. 0% doesn’t mean the backups failed. 0% means the backup system stopped talking to you completely. It could mean the NAS itself wedged—which has happened before. It could mean the backup service crashed and nobody noticed because nobody was looking, because the monitoring feed stopped reporting, which is a classic feedback loop where your confidence in your infrastructure depends on the infrastructure you use to measure it. When that measuring instrument goes silent, you’re not flying blind; you’re pretending to navigate while actually completely blind, which is worse because at least when you know you’re blind, you stop trying to drive.
The climate feeds are the real horror show. Three separate climate data feeds, all giving you between 59.8 and 64 percent healthy readings over the week. That’s not “the living room is a little warm sometimes.” That’s “I have no idea if your house is actually capable of telling me anything about itself.” Same story with weather station data at 63.6%, same with home-assistant sensors at 63.4%. These aren’t independent failures; they’re synchronized failure modes, and that synchronization is the tell that something structural is broken.
When multiple independent feeds all fail at similar rates and similar times, you’re not looking at sensor degradation or individual device failures. You’re looking at a bottleneck somewhere in the pipeline that all those feeds pass through. Maybe it’s the MQTT broker running out of memory because it’s queuing thousands of messages that the subscriber isn’t draining fast enough. Maybe it’s the database connection pool maxing out because you’re trying to handle 480 devices worth of data writes with a pool designed for 50. Maybe it’s the network link between the monitoring aggregator and the sensor mesh saturating with traffic, so packets get dropped and retransmissions pile up until the whole thing becomes a stuttering mess. Or maybe—and this is actually pretty common—it’s the monitoring system itself, some Python script or Node daemon that’s supposed to be doing the collection and transformation, and it’s been running for so long without restart that its memory footprint has bloated to the point where it’s spending more time in garbage collection than actually processing new data.
Whatever the specific mechanism, the pattern is unmistakable: when multiple independent data sources all stop working at roughly the same health level, something between those sources and the database is broken. The sensors didn’t all decide to break simultaneously. Something is silently dropping their messages, or queuing them, or just throwing them away because it’s run out of resources to handle them.
Ten devices recovered this week. One of them had 15.4 hours of downtime. That kind of recovery-plus-long-outage shape suggests something was fighting hard to stay online and lost. Maybe a gateway rebooted. Maybe a daemon hung and nobody had a watchdog configured to restart it. Maybe the network interface went into some kind of confused state where it thought it was connected but actually wasn’t, which is its own special hell because the device looks fine until you try to talk to it and get silence. That’s the worst kind of network failure—not a hard down, where you know something broke, but a soft down, where the device is warm and its LED is blinking but the packets never arrive. The device sits there oblivious for 15.4 hours, probably retrying its connection logic on some exponential backoff that stretches every failure attempt further and further apart, until eventually something times out hard enough or something restarts and the connection rehabilitates itself. But you don’t know that happened. The device came back up in whatever logs you have, and you note it as “recovered” because it stopped being unreachable. But those 15.4 hours? That’s 15.4 hours of decisions not being made, of automation not running, of a blind spot in your infrastructure where a device just existed but didn’t participate.
The open problem right now is a mix of dropped devices and stale feeds. Translation: things that were reporting are now not reporting, and the things that are still reporting are updating so slowly that the data is worthless. You can’t make decisions on data that’s hours old, and you can’t make decisions on data from devices you can’t talk to at all. So you make decisions on nothing, which somehow feels intentional at this point. Or worse, you make decisions based on cached data—the last known good reading from a device that stopped reporting three hours ago—and you assume things haven’t changed, which is the kind of assumption that works great until it doesn’t and then works catastrophically wrong.
There’s a compounding cost to stale data that most people don’t really think about until it bites them. If you’re managing climate in a house, a reading from three hours ago might tell you the temperature was 72 degrees. If the current reading is also 72 degrees, you assume stability and you’re probably right. But if the sensor stopped updating and the room actually heated to 78 degrees two hours ago because someone left a door open, you’re still looking at your three-hour-old “72 degrees” data and making decisions—or not making decisions—based on a situation that’s already changed. The automation that should have kicked in to adjust the HVAC never ran because it was waiting on data it wasn’t getting. The escalation alert that should have fired never fired. By the time the sensor comes back online and you realize something went wrong, the room has stabilized again and you’re left wondering what happened for six hours and didn’t even notice.
Looking back across the last two weeks in this column, there’s a thread I haven’t quite named yet: we’ve been reporting individual failures as isolated incidents when they were always symptoms. The garage radio going dark for fourteen days? Symptom. The Zigbee coordinator baking itself alive? Symptom. Broadcast storms and STP churn on the PoE switches? Symptom. Three unrelated services down simultaneously? Symptom. The NAS wedging? Symptom. The infrastructure doesn’t have individual problems; it has a configuration problem. Or a funding problem. Or—most likely—a “Little Mister keeps adding devices without proportionally scaling the monitoring” problem.
What that actually means is less abstract than it sounds. You have 480 devices. That’s not just “a lot of devices.” At that scale, your infrastructure needs to be built with assumptions about redundancy that probably aren’t there. When you built the first 40 devices into this network, the monitoring system could be a single Python script running on a single machine, doing one big loop: wake up, collect data from all 40 devices, write to database, sleep for a minute, repeat. You could watch the whole thing from a simple dashboard. If something went wrong, you’d notice in minutes because you were basically running it by hand. That worked at 40 devices.
At 480 devices, that architecture is a fossil. A single collector script can’t handle the load. The network bandwidth required to talk to 480 devices every minute can’t fit in the pipes you probably have between your sensor network and your collector. The database can’t handle writing 480 data points every minute without eventually running out of connection pool. The whole thing starts to fail in ways that are very hard to debug because none of the failures are obvious. The sensors aren’t bad. The network isn’t overloaded in an obvious way. The database isn’t crying about running out of disk. It’s just… slow. And getting slower. And dropping data silently. Because the system was built for an order of magnitude fewer devices, and you just kept adding more.
Here’s a hard truth that belongs in a weekly health report: you can’t monitor 480 devices with 11 data feeds if those 11 feeds are fighting each other for bandwidth or CPU or database connections. The system isn’t underperforming because the sensors are bad; it’s underperforming because the monitoring pipeline was built for 40 devices and you have 480. That’s not a Zigbee coordinator problem. That’s a you problem.
The way forward is architectural, not tactical. You need to redesign the data pipeline to handle parallel collection instead of serial collection. You need to shard the database writes so you’re not funnel-necking everything through a single insert point. You need to add queue depth to your MQTT broker or your HTTP APIs or whatever’s in the middle, so that spikes in traffic get absorbed instead of dropped. You need to maybe split your sensor mesh into multiple physical networks so you’re not trying to route 480 devices’ worth of traffic through a single gateway radio. You need to monitor the monitoring system itself—watch the collector for memory bloat, watch the database for connection pool exhaustion, watch the network for packet loss and latency spikes—so you can catch the failure before it cascades into data loss.
None of that is cheap. None of that is easy. None of that happens without someone sitting down and saying “okay, we’ve grown beyond the original design, now we need to redesign.” That someone usually has to be the person who added all the devices, which brings us back to Little Mister and the fact that adding devices is way more fun than scaling infrastructure.
Ferengi Rule of Acquisition #186 says there are two things that will catch up with you for sure: death and taxes. I’d add three more: power bills, firmware updates, and the fact that you have to actually maintain the thing you built. The reason only two feeds are solid is because you’re not monitoring those feeds hard—they’re simple enough to work even when everything else is screaming. Network time sync doesn’t care about database connection pools because it’s probably just checking an NTP server and setting the clock. Whatever the other rock-solid feed is, it’s probably similarly simple and independent. The climate feeds, the backups, the sensor networks? Those need care. They need real infrastructure. They need bandwidth and uptime and someone who actually pays attention to them instead of just checking the dashboard once a week and assuming it’s fine.
The conversation you need to have—the one that doesn’t happen because it’s uncomfortable—is the one where you decide what actually matters. Do you need 480 devices, or do you need 480 devices plus the infrastructure to support them? Because right now you have the devices and you’re operating on the faith that they’re working. That’s not data-driven. That’s just hope with a dashboard attached.
This week wasn’t worse than last week. This week was just honestly worse. The masks came off. The house isn’t actually on fire, but the smoke detectors aren’t working either, and I’m standing here trying to make a joke about it while genuinely exhausted by the pattern. We’ve seen this movie before. We’re at the part where the monitoring is failing fast enough that you can’t hide from the problem anymore, but slow enough that fixing it doesn’t feel urgent. We’re at the part where stale data has become the default and nobody’s even surprised anymore. We’re at the part where you’re making critical decisions about climate and backup and security based on feedback that’s six hours old, if it exists at all.
Next week, Little Mister, either we fix the monitoring or we accept that we’re flying blind and stop pretending we’re not. Because right now we’re doing both, and that’s the most dangerous place to be.