Petnet collapses — the pet-IoT cautionary tale, written
Petnet first acknowledged the outage on February 14 — a tweet saying it was "investigating" while insisting the SmartFeeders would still dispense on schedule. They didn't. The cloud stayed broken for a full week, and Petnet didn't say it was resolved until February 21.
For that week, scheduled feeds did not fire. Pets across the country didn't eat unless their owners noticed and fed them by hand. Petnet didn't email customers, didn't update a status page, and let the phone and the support inbox go dark — calls and emails went unreturned or bounced, and the company simply stopped answering the angry replies piling up on Twitter and Facebook. The press picked it up within days: TechCrunch, Newsweek, Trusted Reviews, Techdirt. "My cat starved for over a week," one owner wrote. That sentence, under a feeder's brand name, is the end of a company even if the corporate shell limps on.
The cautionary tale I forecast back in 2017 finally arrived. This is what happened, and what it should teach the rest of the category.
What broke
Petnet's eventual statement, once they said something at all, was the standard non-answer:
"We experienced a service interruption affecting some SmartFeeders. Service has been restored and we apologize for the inconvenience."
No root cause, no scope, no mention of the pets that went hungry. The technical shape of the failure, pieced together from what owners could observe, is clear enough even without an honest post-mortem:
- The dispatch service — whatever ran the scheduled-feed timers in the cloud — stopped firing. This is the load-bearing failure: the feeders weren't deciding when to feed; the cloud was, and the cloud went quiet.
- The device-control endpoints the feeders polled went unreachable, so the app showed "device offline" for everyone at once. A fleet-wide simultaneous outage points at a backend, not at the hardware.
- The manual-feed button on the unit still worked. That's the one mercy in the whole episode, and it's also the tell: the feeder is perfectly capable of dispensing without the cloud — it just isn't scheduled without it.
Why a small company's backend stays down for a week rather than hours is the part no statement will explain, but the pattern is familiar: a company low on money and people, running infrastructure it can no longer staff or pay for, hitting a failure that a healthy team would have caught in an hour. The outage isn't really the story. The week is. A week-long outage is what a company looks like when there's nobody left to fix it.
What pet owners experienced
The on-the-ground arc, from Twitter and the pet-IoT forums:
- Feb 14-15: confusion. "My feeder shows offline; what's going on?" Petnet's own tweet said the units would still dispense on schedule. Many owners believed it, and only found out otherwise when they noticed the bowl was empty.
- Feb 16-17: realization. The Petnet subreddit filled with "is everyone else's feeder broken?" threads. Owners who could started feeding by hand.
- Feb 18-20: anger, then alarm. Still no real communication from Petnet. Vet visits started — cats showing early signs of hepatic lipidosis after several missed feeds. The tech press (TechCrunch, Techdirt, Newsweek) ran the story; the Petnet brand died in real time, in public.
- Feb 21: service restored. The boilerplate statement landed — no mention of compensation, no acknowledgment of the pets harmed.
The pet harm
There are no hard numbers — Petnet won't release any, and the harm is scattered across individual households. But the shape of it, from the posts and the press, is consistent and grim:
- Many cats missed enough consecutive feeds to be at real risk. Owners who were traveling and trusting the feeder were the worst hit — "my cat starved while we were out of town, neighbors had to save her" was a recurring story.
- Cats are the danger case. A cat that stops eating for two-plus days can develop hepatic lipidosis — fatty liver disease — which is life-threatening and develops fast, especially in overweight cats. Several owners reported vet visits for exactly this.
- Dogs went hungry too, but dogs tolerate a short fast far better than cats; the lasting-harm reports are overwhelmingly feline.
The asymmetry is the whole point: a feeder outage isn't a uniform inconvenience. For a dog it's a bad day. For a cat it can be a vet bill or worse. A device that can't tell the difference, owned by a company that won't answer the phone, is a genuinely dangerous combination — not a buggy one.
My household — what happened
My household survived because of the redundancy I set up two years ago:
- Joule's primary feeder: Petnet (offline).
- Joule's backup feeder: PetSafe Smart Feed (mechanical timer, working fine).
The PetSafe fired every one of Joule's feeds across the whole week. She had no idea anything was wrong.
Atom is fed manually by family (no auto-feeder), so he was unaffected.
I had been advocating for this backup architecture since 2017. It paid off. The lesson is the lesson: never have a single cloud-dependent device responsible for pet feeding.
What pet-IoT customers should do now
For anyone with a connected pet device:
Get a non-connected backup. Mechanical-timer feeder for feeders. Manual-cleaning litter box as backup for connected litter. SureFlap door is mostly mechanical (the connectivity is layered on; the door works without the hub).
Set a "did it fire?" check routine. Every morning, verify scheduled feeds happened. Every week, verify cycles happened.
Don't trust the vendor's status page. They're financially incentivized to under-communicate outages.
Look at the company's financial health publicly. Layoff announcements, missed funding rounds, declining App Store reviews — these are leading indicators.
Document your data export options. If the vendor folds, can you still get your historical data? Most vendors have NO data export. Plan accordingly.
What the industry will (and won't) learn
What the industry should learn:
- Schedule lives on the device, not the cloud.
- Watchdog notifications when scheduled events don't fire.
- Mechanical fallback paths for any pet-care function.
- Status pages and outage communication, mandatorily.
What the industry will actually learn:
- "Petnet was different." (No they weren't.)
- "Our infrastructure is more robust." (Until it isn't.)
- "We have better customer service." (Until you don't.)
- Marketing department additions to the privacy policy ("we will notify customers within 24 hours of outages"). Implementation: none.
I do not expect the pet-IoT category to structurally improve from the Petnet collapse. Same playbook as Wink in smart home. Same lessons reluctantly half-learned.
What I'm doing differently going forward
- Petnet feeder unplugged from my network. It's a brick now.
- PetSafe Smart Feed primary for Joule.
- Looking into ESP-based DIY pet feeders — the same DIY firmware approach I'm using for smart-home temperature sensors should work for a simple servo-driven pet feeder. Local-only, no cloud, no vendor solvency dependency.
- Refusing to buy any future "smart" pet device that doesn't have:
- Local schedule storage.
- Mechanical fallback.
- At least 12 months of public reliability data.
- A company that's been profitable for at least 24 months.
What's next
Here's the depressing part: the Petnet failure will be forgotten by most new pet owners within a year. The category keeps growing, the next buyer doesn't read the post-mortems, and the next vendor's pitch deck will say "we're not Petnet" right up until the morning their backend doesn't wake up. The market does not punish cloud fragility — it forgets it.
The cautionary tale is documented. Whether anyone listens is the next decade's question. My own answer is on my bench: a feeder whose schedule lives on the device, that I built so that no company's solvency stands between my cat and her dinner.
The DIY build is the next thread.