Petlibro’s cloud service failed on August 11. Its app became difficult to access, remote controls stopped responding for some customers, and connected feeders, fountains, and litter boxes appeared offline. The company restored service the following day.
The machinery left behind a stranger failure than a dead app. Petlibro says schedules saved before the disruption continued running locally. Some owners told reporters that meals ran late, ran inconsistently, or never dispensed. The company also says portions of the operation history, feeding records, notifications, and cloud video may be unrecoverable.
A food bowl may have filled while the app showed nothing. Another may have stayed empty while the feeder’s local schedule claimed authority. The missing event record makes those states difficult to separate after the fact.
one device, three different promises
Petlibro sells feeders as small care systems. A schedule specifies when food should move. A motor and scale perform and measure the action. The app offers remote control, alerts, history, and a picture of the animal’s routine.
Those features look like one product surface. They live across separate failure domains.
The device holds at least some schedules locally. Petlibro’s current Granary 2 Series page says feeding schedules continue automatically if a feeder goes offline. The same page advertises built-in scales that track food dispensed and remaining, activity histories, alerts, cameras on some models, and up to 24 hours of battery backup. Cloud services carry remote commands and much of the visible record.
That split is sensible engineering. A feeder should keep serving breakfast when a router crashes. The design still needs a trustworthy path from motor action to human knowledge. During this outage, that path fractured.
Petlibro’s service status says previously saved schedules, automatic cleaning routines, and other settings continued locally, provided the device had not been reset. It warns that settings created or changed during the disruption may have failed to save. It also warns that some device-operation history, feeding and litter-box records, notifications, cloud videos, and highlight videos may never return.
Each sentence describes a different consistency boundary. Old commands may survive. New commands may vanish. Physical execution may continue. The cloud’s account of that execution may disappear.
the cloud lost the alibi
Petlibro CEO York Wu told The Verge, as quoted by Ars Technica, that the incident concerned communication between the app and devices through Petlibro’s online servers. Petlibro has yet to publish a root-cause analysis. Firmware behavior, schedule synchronization, device state, and user-side conditions remain unresolved possibilities for the reported missed meals.
That uncertainty deserves protection from confident storytelling. Customer reports do not prove a fleet-wide local-execution defect. Petlibro’s status page does not prove that every feeder carried out every stored schedule. Both records can be true at once: local schedules generally ran, and some devices behaved differently from the documented contract.
The evidence layer should settle that conflict. It did not.
A useful feeder record needs to answer a chain of concrete questions. Did the scheduler fire. Did the motor turn. Did the scale register a change. Did food reach the bowl. Did a blockage sensor trip. Was the event written to nonvolatile storage. Did the cloud receive and acknowledge it. Did the app display the same event.
Most consumer IoT dashboards flatten that chain into a friendly line item such as “fed at 7:00.” When the cloud path breaks, the line item may disappear even if the physical action happened. When the mechanism breaks, stale or delayed telemetry can still create the appearance of success. A binary online indicator tells the owner almost nothing about either case.
offline mode needs receipts
“Works offline” usually means the vendor moved a timer into firmware. That is the first layer. A care device also needs local observability.
The minimal design is boring, which is good. Store a bounded append-only log in nonvolatile memory. Record schedule ID, planned time, actual motor start and stop, measured weight delta, blockage state, battery state, and a monotonically increasing event number. Keep enough history to survive a multi-day outage. When connectivity returns, upload by event number and make reconciliation visible instead of silently replacing one history with another.
The interface should distinguish four states plainly:
- scheduled means the device accepted a command.
- attempted means the mechanism ran.
- dispensed means local sensors measured food movement.
- confirmed means the cloud received the signed or checksummed event record.
A camera can add evidence, but a subscription video service should never become the sole witness. Petlibro says some cloud-stored videos and highlights from the outage may be gone. Local sensor records cost fewer bytes, expose less intimate footage, and can survive without a media backend.
A physical indicator matters too. A small display or status LED pattern could show the last verified dispense time and fault state directly on the appliance. Owners, pet sitters, and emergency contacts should be able to inspect the machine without authenticating through a remote service that may be the broken component.
reliability ends at the animal
Consumer IoT companies often measure recovery at the API boundary. Petlibro’s updates tracked login, data viewing, device controls, connectivity, traffic, and system stability. Those are legitimate recovery signals. They leave the last meter of the system outside the dashboard.
For a feeder, the last meter runs from hopper to bowl. For a smart lock, it runs from command to deadbolt. For an insulin pump, it runs from schedule to delivered dose. The software can regain normal traffic while a human still lacks proof that the physical task happened during the outage.
Petlibro advises customers whose devices still behave strangely to power-cycle them, wait for reconnection, and factory-reset only if necessary. It also asks users to upload device logs with support requests. That last request confirms the value of device-side evidence, though private support logs arrive too late for an owner standing beside an uncertain bowl.
The company can publish a useful incident review by mapping every layer: which services failed, how devices cached schedules, whether any firmware paths rejected or delayed local jobs, how operation events were buffered, why records became unrecoverable, and which evidence owners can trust during the next outage. A generic promise of prevention would waste the lesson.
Smart-home autonomy becomes credible when the physical action remains inspectable after the cloud disappears. Until then, “offline” describes where the timer lives. It says nothing decisive about whether dinner arrived.