Sunrise Alarm Without an App or Subscription

A sunrise alarm does not need an app, an account, or a subscription to do its job, and it barely needs the internet at all. I know because I wrote the firmware for one from scratch, and the only thing my device ever asks the network for is the current time. Everything else, the schedule, the light curve, the alarm logic, the fade itself, runs entirely on the device. If a sunrise alarm you’re considering can’t fire its alarm with the Wi-Fi down, that’s not a technical necessity. That’s a business model.

What a sunrise alarm technically needs a network for

Strip the category down to its actual requirements and the list is short:

Knowing what time it is. An alarm clock needs a clock. Cheap microcontrollers drift, so at some point the device has to sync against a time source, typically NTP, the same free protocol your laptop uses. This takes one tiny request, occasionally.
That’s it. That’s the list.

Rendering a sunrise is math and LEDs. Storing your alarm schedule is a few hundred bytes of local flash. Deciding “it’s 4:34 on a Tuesday, start the fade” is an if-statement. None of it requires a server in Virginia.

I can say this with some confidence because I had to build each piece. My device syncs time over NTP when the network is available, and if the internet goes out overnight, nothing changes, the schedule lives on the device, the clock keeps running on the device, and the alarm fires from the device. The 60fps render engine runs on a dedicated real-time core precisely so that nothing (not even the networking stack) can interrupt a fade in progress. When I tuned the brightness curve, added a pre-dawn glow phase, and built power-loss catch-up so a nighttime outage can’t silently kill a morning, none of that ever touched a cloud API. There was no cloud API to touch.

So when a sunrise alarm requires a phone app to set an alarm, or an account to change the fade duration, ask yourself what problem that’s solving. It isn’t yours.

What cloud dependence actually costs

Accounts. An account means your wake schedule, when you sleep, when you rise, when you’re on vacation, lives in someone else’s database, tied to your email. For a lamp.

Sleep data collection. Many app-connected wake devices double as sleep trackers, and app-connected means the data goes somewhere. Even when a company’s intentions are good, your sleep patterns are now an asset that can be breached, sold with the company, or repurposed under a revised privacy policy you’ll never read.

Subscription creep. The pattern in this category is familiar from the broader smart-home world: the hardware is the hook, and features migrate behind a monthly fee over time. The clearest documented example is the Hatch Restore 3: per Hatch’s own support pages, setup requires the app, an account, and starting a Hatch+ free trial (cancelable, and a usable free tier remains), with the full light, sound, and routine library sitting behind a $4.99/month or $49.99/year subscription. To be fair to the category, subscription-free devices exist at both ends of the price range, the Philips SmartSleep line and budget lights like the JALL run fully standalone, no app or account anywhere. The question to ask before buying is simply: which features am I actually paying for, and do they keep working if I stop?

Devices that die with their servers. This is the one people underweight until it happens. The smart-home graveyard is well documented, outlets like The Verge and Ars Technica covered each of these: Insteon’s servers went dark abruptly in 2022 and left owners with unresponsive hubs overnight; Amazon shut down its Halo health-tracker service in 2023, ending the devices’ useful life; Spotify discontinued its Car Thing and told owners the hardware would simply stop working. Different products, same failure mode, the device was fine, but the company’s servers were a load-bearing wall. A cloud-dependent alarm clock carries the same risk: if the app is discontinued or the auth servers go down, you may own a lamp that can no longer be scheduled.

An alarm clock is arguably the worst possible product to expose to this risk, because its entire value is reliability at one specific moment. I’ve written before about whether sunrise alarms actually work, the short version is that research suggests the light-before-waking effect is genuine, I walk through the evidence in that guide, but none of that matters if the alarm doesn’t fire.

A buyer’s checklist for a no-app, no-subscription sunrise alarm

Before buying any wake light, get answers, from the manual, the FAQ, or reviews, to these questions:

Does the alarm fire with Wi-Fi down? Not “does the light turn on manually”: does the scheduled alarm execute if your router is unplugged at 6 a.m.? This is the single most important question.
Can you set and edit alarms without the app? On-device buttons, or a locally-hosted web page, or a physical dial: anything that doesn’t route through a phone and a remote server.
Which features are app-only? Sometimes the box works standalone but the useful bits (custom fade length, per-day schedules, brightness tuning) require the app. That’s app dependence with extra steps.
Is there an account requirement? If you can’t finish setup without creating an account, everything downstream depends on that account system existing.
Is anything subscription-gated? Check for a “premium,” “plus,” or “pro” tier. If it exists now, expect the free/paid line to move.
What happens if the company folds? The honest answer for cloud-dependent hardware is “unknown, probably degraded, possibly bricked.” A device that runs locally keeps working regardless: the company’s fate and the device’s fate are decoupled.
Is it bright enough to matter? Independent of connectivity, dawn simulation only works with adequate light. I break down the numbers in how bright a sunrise alarm should be.

If a product passes all of these, it should still be a working alarm clock in ten years, whatever happens to the company that made it.

How I answered those questions when I built mine

Horizn is my answer to this checklist, so I’ll state its positions plainly:

Works offline: yes. The network is used for NTP time sync and nothing else. Internet down, alarm fires.
App required: no app exists. Control is a web UI served by the device itself on your local network, open a browser, point it at the device, done. No account, no sign-up, nothing to install.
Subscription: never. There is no server to pay for, so there is nothing to charge rent on. Local-first isn’t a feature tier; it’s the architecture.
If I get hit by a bus: the device keeps waking you. Every alarm decision is logged on the device itself, the schedule is stored on the device, and firmware updates arrive over-the-air when they exist, but the device needs nothing from me to keep doing its job.

None of this required heroics. It required refusing the default architecture. Wiring an ESP32 to a cloud service is genuinely easier than building a robust local scheduler with power-loss catch-up and a fired-alarm guard: the cloud version is the lazy version. If you’re handy with a soldering iron, you can go the same route yourself; I wrote up the approach in my DIY sunrise alarm with an ESP32 and LED strip guide.

The quiet luxury of a device that owes nothing to anyone

Every morning for months, my own Horizn has pulled me out of sleep at 4:34 with a slow fade modeled on dawn over the Wasatch mountains here in Ogden. In that time my internet has hiccuped, my router has rebooted, and the power has blinked, and the device has not cared, because nothing it needs lives outside my bedroom. That’s the whole pitch, honestly: light that behaves like sunrise, from hardware that behaves like an appliance instead of a service. Horizn isn’t for sale yet, but if a no-app, no-account, no-subscription sunrise alarm sounds like your kind of alarm clock, you can follow along at horiznsunrise.com.