Smart Pet Feeders Failed During a Cloud Outage

Your pet feeder has one job. One. And yet.

Last week, thousands of pet owners discovered a hard truth about the "smart" devices they'd come to trust with their animals' daily meals: the intelligence lives in the cloud, and clouds go down. According to The Verge, a service disruption at Petlibro — one of the most popular smart feeder brands on the market — began on Tuesday and knocked users' feeders, litter boxes, and water fountains offline. Reddit filled up fast with frustrated owners reporting missed feedings and silent devices.

MLQ.ai reports that Petlibro said the disruption was resolved by Thursday — roughly 48 hours later. The company maintained that schedules stored locally on devices should have continued to run, but acknowledged that any settings changed during the outage may not have been saved. That's a meaningful asterisk. If you'd adjusted your cat's feeding schedule on Monday night and the outage rolled in Tuesday morning, your "locally stored" schedule was whatever it was before you changed it.

Notebookcheck.net digs into specifics: RFID and Granary feeders missed scheduled feedings outright, some Dockstream water fountains stopped pumping entirely, and Luma litter boxes stopped running cleaning cycles. So while Petlibro's "local settings" defense isn't wrong exactly, it also doesn't capture the full picture of what users actually experienced.

This isn't new. It's a pattern.

Here's the thing that makes this story more than a one-week inconvenience: we've been here before, and the previous version ended much worse.

In February 2020, a company called Petnet — a different brand, same product category — suffered a cloud outage that knocked its smart feeders offline for a week. According to Slashdot, the outage didn't just freeze the feeders — Petnet's customer service went dark too, leaving users with no information and no recourse. The company eventually apologized and pushed a patch, but the damage was done. Then, just two months later — still citing the chaos of early COVID — Petnet shut down entirely. Devices that owners had paid for became inert plastic. No refund, no migration path, no backup feeding solution for their pets.

That's not a cautionary tale at the edge of the industry. That's a company that went from "cloud outage" to "company doesn't exist anymore" in about two months, taking its users' hardware down with it.

Petlibro resolved its outage in 48 hours and kept the lights on — that's a materially different outcome. But the structural vulnerability that both incidents expose is identical: the device you bought and placed in your home, the one doing something as basic and time-sensitive as feeding a living animal, is only as functional as the relationship between your Wi-Fi and a server you don't control.

The "offline mode" question

The interesting technical debate embedded in this outage is what "local" actually means for IoT devices, and how much weight manufacturers can honestly put on that word.

Petlibro's position — that locally stored schedules would continue running — is the kind of thing that sounds reassuring in a press statement and gets complicated in practice. Local execution depends on firmware design decisions made long before any outage. If authentication tokens need to be renewed via the cloud, or if the device checks in with a server before dispensing food, "local" scheduling can fail even when the underlying hardware is fine. Users reporting missed feedings despite having schedules set suggests the local fallback wasn't as clean as the company implied.

This is a genuine design tension, not a simple engineering failure. Cloud connectivity is what makes these devices useful in the first place — remote scheduling, app control, feeding history, camera integration. Strip that out and you've got a $15 mechanical timer with a Bluetooth logo on it. Manufacturers aren't making cloud-dependent devices because they're lazy; they're doing it because that's what the product category demands.

But "useful" and "reliable" are not the same requirement, and for devices that manage something time-sensitive — feeding, medication dispensers, irrigation systems — the failure mode matters in a way it simply doesn't for, say, a smart lightbulb that turns off during an outage. 🐱 A dark room is an inconvenience. A missed feeding for a diabetic pet on a strict schedule is a health issue.

What would "responsible design" even look like?

The honest answer is: it depends on how much you trust your hardware.

True offline resilience for a smart feeder would mean the device can execute its full core function — dispensing food on a schedule — with zero cloud dependency, treating connectivity as a feature layer rather than a load-bearing wall. This is technically achievable. Some manufacturers have moved in this direction, particularly in categories like home security where users have pushed back hard on cloud dependency after high-profile failures.

The friction is commercial. Offline-capable devices are harder to build, require more onboard processing, and reduce the data companies collect — which, in many IoT business models, is part of the product. When your smart feeder tracks feeding patterns and syncs to an app, that data has value. Full offline mode short-circuits some of that value exchange.

There's also a consumer education problem that's genuinely hard to solve. The marketing for these devices — "never worry about feeding your pet again!" — sets reliability expectations that the underlying architecture can't always meet. Most buyers don't read terms of service carefully enough to understand that their feeder's functionality is contingent on a third party's uptime. That gap between expectation and architecture is where outrage lives.

The regulatory vacuum

It's worth naming something that's easy to skip past: there is no regulatory framework in the U.S. that requires IoT manufacturers to maintain service uptime, provide offline fallbacks, or even notify users before shutting down a cloud service entirely. When Petnet went dark, it had no legal obligation to keep its servers running so that the hardware users had purchased would continue to function.

The EU's Cyber Resilience Act — which passed in 2024 and is being phased in — includes provisions around product support lifetimes and vulnerability handling for connected devices, but it doesn't specifically address the service-shutdown-kills-your-hardware scenario in a robust way. In the U.S., the FTC has taken some interest in "bricking" products through software updates, but enforcement is sparse and focused on egregious cases.

Which means, for now, consumers are mostly on their own. The protections they have are the ones manufacturers choose to provide — and those choices are made in a market where the upside of cloud features is obvious and the downside of an outage is borne almost entirely by the user.

So where does this leave pet owners?

The Petlibro outage resolved. Their communication, while imperfect, was faster than Petnet's in 2020. That's progress of a sort. But the category's structural dependency on cloud infrastructure hasn't changed, and neither has the consumer's exposure when that infrastructure hiccups — or disappears entirely.

The honest read is this: smart feeders are convenient until they're not, and the "not" can arrive at any time, for reasons entirely outside your control. If you're using one, it's worth knowing whether your device has a manual override, what its actual offline behavior is, and whether you have a backup plan. Not because outages are constant — they're not — but because the device's job is important enough that "usually works" probably shouldn't be your only risk management strategy.

The bigger question, though, is whether "smart" device categories that handle time-sensitive, life-adjacent functions — feeding, medication, monitoring — should be held to a different standard than smart lights and smart speakers. That's a conversation the industry, and probably regulators, haven't fully had yet.

Your cat is waiting. 🐾