There is a small board on a shelf that never sleeps.
No fan noise. No screen. Just a faint warmth if you press a finger against it long enough. The LED stopped blinking weeks ago. Or maybe it still is, and you stopped noticing.
It's still running.
And that's where people get it wrong.
They think "running" means stable. Predictable.
Done.
It doesn't.
It Doesn't Stay the Same Device
The first version of your ESP32 is the one you flashed. Clean. Intentional. Every line of code accounted for.
That version doesn't last.
Over time, the device drifts. Not in some mystical sense. In a very literal accumulation of state. Buffers fill and empty. Memory fragments. WiFi reconnects hundreds of times. Timers tick past thresholds you never tested. Edge cases stop being edge cases because given enough hours, everything happens.
You wrote logic assuming a day. Maybe a week.
Leave it for a month and you're no longer running your code. You're running everything your code didn't anticipate.
There's a difference.
Memory Starts to Behave Like a Surface, Not a Container
On paper, the ESP32 has enough RAM for most lightweight systems. In practice, that RAM becomes uneven over time.
Heap fragmentation is the quiet one. It doesn't crash immediately. It just reshapes what's available. Allocations that worked on day one start failing in strange ways. Not clean failures either. Partial allocations. Corrupted data.
Functions returning values that feel slightly off.
You restart the device and everything looks fine again.
That should bother you.
Because it means the system only works in a freshly initialized state. Which means it's not stable. It's just temporarily aligned.
Long-running devices expose this quickly.
Especially if you're doing dynamic allocation, string operations, or anything involving WiFi stacks and JSON parsing.
It's not dramatic. It's worse than that. It's subtle.
WiFi Becomes a Personality Problem
WiFi on the ESP32 is good. Until it isn't.
When you leave a device running continuously, you start to see patterns that don't show up in short sessions. Networks drop for a few seconds. Routers rotate channels. DHCP leases expire. Signal strength shifts based on time of day, interference, other devices.
Your ESP32 has to live through all of that.
And most sketches don't handle it properly.
They check WiFi.status() and reconnect. That's not enough. Sometimes the stack thinks it's connected when it isn't. Sometimes reconnect loops lock up other tasks. Sometimes the device enters a state where it's technically online but functionally dead. No data moves.
You won't notice unless you're logging externally.
From the outside, it looks fine. The LED is still on.
Inside, it's stalled.
Heat Is Low, But Not Zero
People treat the ESP32 like it's immune to heat because it runs cool.
That's only half true.
Yes, it won't burn your fingers. But over long durations, even small thermal fluctuations matter. Especially if the board is enclosed, or sitting near other electronics, or powered through questionable regulators.
Temperature affects timing. Stability. RF performance.
Not enough to break things instantly. Enough to shift behavior over time.
You start seeing weird resets. Slight timing drift. Sensor readings that slowly diverge.
Nothing obvious. Just enough to make you doubt your data.
Power Quality Starts to Matter More Than Code
For short runs, almost any USB cable and power source will do.
For 24/7 operation, power becomes the foundation.
Cheap adapters introduce ripple. Long cables drop voltage. Sudden load spikes from WiFi transmissions can dip the supply just enough to trigger brownouts.
The ESP32 has brownout detection, but many people disable it when it becomes annoying during development.
That decision comes back later.
Now instead of clean resets, you get undefined behavior. Partial execution. Corrupted state.
A device that "runs fine" for hours suddenly locks up after three days.
You blame the code. It might not be the code.
Time Stops Being Abstract
Most hobby projects ignore time beyond millis().
Leave something running for weeks and time becomes a real dependency.
Timers overflow. Scheduling drifts. Events that rely on precise intervals begin to slide. If you're syncing with external systems, even small inaccuracies compound.
Without NTP or some form of correction, your device's sense of time slowly diverges from reality.
At first it's seconds. Then minutes.
Then your logs stop lining up with anything else.
If your system depends on ordering events, that's not a minor issue.
Logging Becomes the Only Truth
When a device runs continuously, you stop being present for most of its behavior.
That means your understanding is only as good as your logs.
And most ESP32 setups barely log anything.
A few serial prints during development. Maybe some debug output. Then it gets removed to "clean things up."
Now something goes wrong at hour 72 and you have no record of what led to it.
You're blind.
Real 24/7 systems treat logging as a core feature, not an afterthought. Even if it's just rotating logs on an SD card or pushing minimal telemetry to a server.
Without that, you're guessing.
And guessing feels a lot like debugging until it doesn't.
The Device Starts Interacting With the Real World
This is the part people underestimate.
A continuously running ESP32 stops being a test object and becomes part of an environment.
It interacts with networks that change. Power that fluctuates. Inputs that aren't controlled. People who don't know it exists.
Maybe it's scanning RFID tags. Maybe it's reading sensors. Maybe it's acting as a node in something larger.
Over time, it accumulates context.
Patterns emerge. Not in a clean dataset sense. In a messy, lived-in way. Missed reads. Duplicate events. Noise that wasn't present during testing.
You start realizing your logic was built for a lab, not for reality.
And reality is not consistent.
Stability Is Engineered, Not Implied
Leaving an ESP32 running 24/7 doesn't automatically make it stable.
It reveals whether it is.
Most setups fail this test in quiet ways. Not explosions. Not obvious crashes. Just gradual degradation. A system that becomes less correct over time.
To counter that, you have to design for longevity from the start.
Not complicated changes. Just intentional ones:
- Watchdogs that actually reset the system when it stalls
- Periodic soft reboots to clear state
- Defensive memory handling instead of optimistic allocation
- Real reconnection logic for WiFi, not just retries
- External logging so you can see what happened when you weren't there
None of this is glamorous.
But it's the difference between a project and a system.
It Becomes Something You Don't Fully Control
There's a point where a long-running device stops feeling like a tool and starts feeling like a process.
It runs whether you check it or not. It fails in ways you didn't directly cause. It recovers sometimes. Other times it doesn't.
You can tighten it. Monitor it. Reset it.
But you don't sit inside every execution path anymore.
That distance matters.
Because it forces you to think differently. Less about writing code that works now. More about writing code that survives being left alone.
The Quiet Shift
If you've only ever powered your ESP32 during active sessions, you're seeing a curated version of it.
Clean boots. Short timelines. Controlled inputs.
Leave it running for weeks and you get the unfiltered version.
Not broken. Just honest.
It shows you where your assumptions were thin. Where your system depends on luck. Where stability was implied instead of built.
Most people don't run their devices long enough to see this.
Which is why their projects feel solid.
Until they aren't.
Feel like supporting the publication? Look no further than my curated guides on cybersecurity, diy electronics, and more on my gumroad. The guides below pair very well with the content of this post, and these guides are currently keeping me "fed 'n' bed" as I am currently in a unique and challenging situation in my life. Any support means the world, and includes lifetime updates and access to my personal email for debugging/discourse. Thanks again, if you read this far- you are obviously on the same wavelength. Keep pushing.
The BadUSB Factory: Convert Any Flash Drive Into a Weapon
The Ultimate Arduino Project Compendium
Top comments (0)