This content originally appeared on Level Up Coding – Medium and was authored by Salman Azam
$2,000 smart beds stopped working when AWS went down. No offline mode, no manual controls. Why cloud dependency is breaking our products.
At 3 AM on October 20, 2024, something absurd happened across bedrooms in America.
Thousands of people found themselves trapped in overheating beds, stuck in uncomfortable positions, unable to control their own mattresses.
The culprit? An Amazon Web Services outage that exposed a fundamental flaw in how we’re building connected products.
The Night Everything Went Wrong
Eight Sleep manufactures premium “Pod” mattress covers that promise to revolutionize your sleep.
Using water-cooled coils and sophisticated temperature regulation, these $2,000+ devices track biometric data and adjust conditions throughout the night.
They’re controlled entirely through a mobile app connected to the cloud.
When AWS’s US-EAST-1 region began experiencing “increased error rates and latencies” in the early morning hours, Eight Sleep’s entire product ecosystem collapsed.
The company’s backend infrastructure, hosted on AWS, became unreachable. And because there was no offline mode, no local controls, and no manual override, customers were left with expensive heating pads they couldn’t turn off.
Tech enthusiast Alex Browne captured the surreal nature of the situation perfectly: “Backend outage means I’m sleeping in a sauna.” His Pod had locked itself nine degrees above room temperature with no way to adjust it.
Others reported beds stuck in inclined positions. Some devices became completely unresponsive.
By mid-morning, Downdetector had logged over eight million disruption reports as the AWS outage cascaded across multiple services, but few failures were as viscerally uncomfortable as being trapped in a malfunctioning bed.
The Engineering Failure Nobody Caught
From a software engineering perspective, Eight Sleep’s architecture represents everything wrong with modern IoT design.
Any device that controls physical hardware affecting human comfort or safety should follow three fundamental principles:
Local Fallback Mode: Core functionality must work without internet connectivity. Temperature controls, position adjustments, basic operations, these should run locally on the device itself.
Manual Override: Physical buttons or controls that bypass all software layers. If the app fails, if the cloud dies, if everything goes wrong, users need a way to manually control their device.
Graceful Degradation: When connectivity fails, the system should default to safe, comfortable settings, not maintain whatever state was last active, and certainly not lock users out of all controls.
Eight Sleep implemented none of these safeguards. Their product depends entirely on continuous cloud connectivity for basic functions that have no business requiring internet access.
Temperature regulation is fundamentally a thermostat problem, not a distributed systems problem. The decision to route every temperature adjustment through AWS servers adds complexity, creates failure points, and provides no meaningful benefit to users.
The Question Nobody Asked
Why does a mattress need internet connectivity to function at all?
Let’s break down Eight Sleep’s features:
Temperature Control: This could be handled by an onboard microcontroller with local app connectivity via Bluetooth. No cloud required.
Position Adjustment: A motor with physical controls. Cloud connectivity adds nothing but failure modes.
Biometric Tracking: The only feature that genuinely benefits from cloud connectivity for data storage and analysis. But even this should sync opportunistically when connection is available, not make the entire device dependent on it.
App Control: Could work via local Bluetooth or WiFi direct connection. Many smart home devices successfully use this approach.
The architecture Eight Sleep chose — routing every command through cloud infrastructure — wasn’t driven by technical necessity. It was driven by business models that depend on continuous connectivity for data collection, subscription enforcement, and control.
When “Smart” Becomes Stupid
Eight Sleep isn’t alone in this pattern. We’re living through an era where manufacturers are adding internet connectivity to everything, often making products worse in the process.
Smart refrigerators that can’t maintain temperature when WiFi drops. Connected coffee makers that won’t brew without cloud access.
Thermostats that freeze (literally) when servers go down. Light bulbs that become expensive paperweights if the company goes bankrupt and shuts down their servers.
The common thread? Companies prioritizing data collection and recurring revenue over product reliability and user autonomy.
When AWS experienced its outage, multiple categories of products failed simultaneously.
Banking apps, gaming platforms, streaming services, these disruptions were inconvenient.
But when someone can’t adjust their bed temperature at 3 AM, that’s not inconvenience. That’s a fundamental product failure.
The Real Cost of Cloud Dependency
The Eight Sleep incident highlights several concerning trends in hardware development:
Single Point of Failure: Depending on any single cloud provider creates systemic risk. When AWS goes down, it takes huge swaths of the internet with it. Your product shouldn’t be one of them.
Engineered Helplessness: Users lose agency over products they own. They can’t fix issues, can’t use offline modes, can’t override bad decisions. They’re entirely dependent on external systems functioning correctly.
Privacy Invasion: Constant cloud connectivity means constant data collection. Your sleep patterns, bedroom temperature preferences, biometric data, all flowing to corporate servers. Not because it improves the product, but because that data has value.
Planned Obsolescence: When the company decides to shut down servers, or goes out of business, or gets acquired and the new owner kills the product line, your device becomes e-waste. Not because it’s broken, but because it was designed to be dependent.
What the CEO’s Response Reveals
After the outage, Eight Sleep CEO Matteo Franceschetti promised they would “work the whole night + 24/7 to build an outage mode so the problem will be fixed extremely quickly.”
This statement is both reassuring and damning.
Reassuring because they’re acknowledging the problem and committing to fix it. Damning because it reveals this fundamental safeguard didn’t exist before shipping thousands of units.
An “outage mode” isn’t a feature you add after launch. It’s a core requirement you design for from day one. Any product review, any engineering assessment, any basic risk analysis should have caught this.
The fact that Eight Sleep shipped a product where cloud connectivity failure makes the device unusable suggests deeper issues in their development process.
Either they never considered this failure mode, or they considered it and shipped anyway.
Neither option inspires confidence.
The Pattern Across IoT
This isn’t unique to Eight Sleep. It’s endemic across the entire “smart home” industry.
In 2024, a security researcher found exposed AWS keys in Eight Sleep’s infrastructure that could have allowed remote access to customer devices.
The company patched it, but the vulnerability’s existence points to larger questions about how seriously IoT companies take security and reliability.
Similar incidents happen regularly:
- Smart locks that won’t open when cloud services go down
- Security cameras that can’t record without internet connectivity
- Thermostats that lose all scheduling when offline
- Connected appliances that become “dumb” appliances the moment WiFi drops
Each incident follows the same pattern: features that could work locally are unnecessarily dependent on cloud infrastructure, and when that infrastructure fails, the product becomes partially or completely unusable.
How to Build IoT Right
There’s a better way to design connected products. It requires discipline and a user-first philosophy, but it’s entirely achievable.
Local-First Architecture: All core functionality runs on the device. Cloud connectivity enhances features but isn’t required for basic operation.
Opportunistic Syncing: Data syncs to the cloud when available, but the device continues functioning normally when offline.
Physical Overrides: Manual controls that work regardless of software state. A button that always turns the device off, always adjusts temperature, always provides user control.
Transparent Failure Modes: When things go wrong, communicate clearly. Show connection status. Explain what features are unavailable. Default to safe, comfortable states.
Open APIs and Local Control: Allow users to integrate with home automation systems via local protocols. Don’t force everything through proprietary cloud services.
Many smart home products follow these principles successfully. Philips Hue lights work via local bridge connectivity. HomeKit devices use local communication when possible. Home Assistant runs entirely locally by design.
These approaches prove you can have sophisticated, feature-rich smart devices without forcing users into cloud dependency.
The Regulatory Question
Should there be standards for IoT reliability? Should companies be required to implement offline modes for devices controlling physical environments?
Currently, regulation lags far behind technology. Companies can ship products with arbitrary dependencies and failure modes. When those products fail, users have little recourse beyond social media complaints and negative reviews.
Some regulatory frameworks are emerging. The UK is considering IoT security standards. The EU has proposed right-to-repair legislation that touches on software dependencies. But nothing specifically addresses the issue of cloud-dependent hardware.
Perhaps there should be. When a product failure can trap someone in an overheating bed at 3 AM, that’s a safety issue, not just a user experience problem.
What Users Can Do
Until regulation catches up, buyers need to evaluate IoT products more critically:
Ask About Offline Functionality: Before purchasing, explicitly ask what features work without internet. Get specific answers.
Check for Manual Controls: Physical devices should have physical overrides. If everything requires an app, consider alternatives.
Research Company Stability: A startup’s cloud-dependent product becomes e-waste if the company folds. Established companies or open protocols provide more longevity.
Read Privacy Policies: Understand what data is collected and why. Continuous connectivity usually means continuous data collection.
Consider Non-Smart Alternatives: Sometimes the “dumb” version of a product is more reliable, more private, and just as functional.
The Bigger Picture
The Eight Sleep incident is a perfect microcosm of where we’ve gone wrong with connected technology.
We’ve added internet connectivity to products that don’t need it, creating complexity without benefit.
We’ve made users dependent on external systems they don’t control.
We’ve prioritized data collection and recurring revenue over reliability and user autonomy.
When AWS goes down and you can’t use your bed, that’s not progress. That’s not innovation.
That’s engineering failure dressed up in marketing language about “smart” features and “connected” experiences.
A mattress should be a mattress first. Temperature controls should work locally. Position adjustments shouldn’t require API calls to Amazon’s data centers. These aren’t controversial positions, they’re common sense.
Moving Forward
The good news is this is fixable. Eight Sleep can implement offline modes, local controls, and proper fallback behavior. Other IoT companies can learn from this incident and design better architectures from the start.
But it requires a philosophical shift from “how can we collect more data?” to “how can we make the most reliable product?”
It requires viewing cloud connectivity as an enhancement rather than a requirement.
It requires respecting users enough to let them control products they own, even when the internet is down.
Your $2,000 bed should work as a bed when AWS is offline. Your smart thermostat should regulate temperature when WiFi drops. Your connected door lock should still lock and unlock with physical keys.
Smart features should be additive, not mandatory. They should enhance products, not make them dependent on external systems that can fail at any moment.
Until the industry embraces these principles, we’ll keep seeing incidents like the Eight Sleep outage. Products that fail in absurd ways. Users trapped by unnecessary dependencies. And a growing realization that maybe, just maybe, not everything needs an internet connection.
Have you experienced failures with smart home devices? What features do you think genuinely benefit from cloud connectivity versus what could work locally? Share your experiences in the comments.
The Smart Mattress That Failed When the AWS Cloud Crashed was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Level Up Coding – Medium and was authored by Salman Azam