I'm making a simple Arduino web server and I want to keep it turned on all the time. So it must endure to stay working continuously.

I'm using an Arduino Uno with a Ethernet Shield. It's powered with a simple outlet power supply 5V @ 1A.

My Questions:

  • Will I have any problems leaving the Arduino turned on all the time?
  • Is there some other Arduino board better recommended for this?
  • Are there any precautions that I need to heed regarding this?
  • First question!
    – TheDoctor
    Commented Mar 17, 2014 at 0:01
  • Moderator note: we seem to be getting a lot of answers that state that it worked in their situation. If you have something technical to add to the question, feel free to answer. However, the technical answers seem to cover that it works. If you absolutely must state that your situation worked, it'd be better to add a comment. Commented Jul 18, 2014 at 18:50

11 Answers 11


You shouldn't have any issues keeping it on all the time, however, some thing to consider is any counters you may have, like the use of millis().

From the Arduino docs on millis:

This number will overflow (go back to zero), after approximately 50 days.

So for projects that are on for long periods of time, you may not see an issue immediately but something like this could pop up and cause errors down the road.

  • 20
    To be precise, millis is a uint32_t variable, so it will overflow ("go back to zero") in 4294967296 milliseconds, which is ~49.7 days, ~1193 hours or ~71582 minutes. Commented Feb 12, 2014 at 7:10
  • 5
    Then all you have to do is use another uint32_t that increments when the first rolls over. Then you can enjoy roughly 5.846×10^8 years between rollovers.
    – 80HD
    Commented Feb 15, 2014 at 5:29
  • 4
    if you do millis()-startTime (with start time as a unsigned long, aka uint32_t), you'll always get a valid result unless more than one overflow is happened
    – Lesto
    Commented Apr 4, 2014 at 10:14
  • 5
    The millis() overflow never has to be a problem. See millis() overflow ... a bad thing? for more details. Basically if you calculate time intervals by subtraction, using the appropriate data types, you will never have an issue.
    – Nick Gammon
    Commented Jul 2, 2015 at 22:50
  • 2
    Even if one doesn't use millis directly, I wonder whether one can be confident that neither of the imported libraries does.
    – Michael
    Commented Mar 18, 2016 at 16:48

A couple of things to keep in mind (outside of @Sachleen's mention of millis()):

  • Like any electronics, heat can be disruptive. The micro-controller itself isn't likely going to be a huge issue from the perspective of heat, but other components like the power supply might cause issues.

  • If your code uses EEPROM.write(), be aware that the EEPROM in your Uno's ATmega328P is only rated for 100,000 writes.


Running the Arduino 24/7 Shouldn't be a problem.

But be sure that you have a case that allows for ventilation and you keep it in a well ventilated area. Just like computers, if you do not keep them in an environment that can keep them cool, they will not stay cool.

Server load also should be a thing to consider, the more load there is on the server the more processing it has to do, and the more heat it will generate.

  • 3
    The ATmega does not have traditional low-power modes like normal computers, so load is irrelevant. If you're not doing active computation, it's just spin-waiting. Power consumption when running is actually pretty much static (except things like writing to the EEPROM/flash), at least for the ATmega MCU. There may be variations in the ethernet interface power draw determined by traffic loading, but nothing is likely to generate enough heat to be an issue unless it's in a perfect vacuum or on a heater or something. Commented Feb 12, 2014 at 7:15
  • 1
    Atmega328p has a low power sleep mode that draws ~0.1 uA.
    – JRobert
    Commented Apr 4, 2014 at 19:36
  • 2
    Which would only be relevant if the code actually puts the processor to sleep. Commented Apr 7, 2014 at 15:50

Keep in mind that the flash and EEPROM have limited lifetimes (about 10,000 and 100,000 write cycles respectively) so if you're doing a lot of writing to those, they may become corrupted. In a test I did, an external EEPROM took about 3 days to start becoming corrupted.

  • 1
    While the documentation may list 10k cycles, many tests have shown ~100k is where problems start to occur.
    – Ron
    Commented Feb 21, 2014 at 6:51
  • EEPROM lifetime is minimum 100,000 write cycles according to the datasheet. I think I remember reading a test where corruption started at close to one million writes.
    – user2973
    Commented Jul 17, 2014 at 17:03

We've been running our Arduino-based RFID access system at Bloominglabs Hackerspace in Bloomington IN since late 2011 and aside from a couple power outages and software updates it runs around the clock, no problem. More recently we added a networked thermostat, same deal - it's running round the clock.

  • I too have an RFID access system running 24/7. The only time it "fails" is if the power goes off, because it runs from mains power. This has been running since 2011 with no issues.
    – Nick Gammon
    Commented Jul 2, 2015 at 22:53
  • Haha, hey Steve!
    – deltaray
    Commented Apr 8, 2016 at 4:11
  • @NickGammon Yes, your system is cool, but why is auth not based on card DATA, but only token UID? Please show us a clever solution.
    – user2497
    Commented Nov 4, 2017 at 21:40
  • what's your point? that's unrelated to the poster's question.
    – sdcharle
    Commented Nov 6, 2017 at 1:11

Arduinos can run without issues for a really long time, though depending on local conditions and the intensity of computation you may have to attach heat sinks.

In addition, keep it well ventilated.

It depends on the program being used, too, if your server is serving a page every now and then, it shouldn't be an issue, but if you expect constant traffic then the Arduino may heat up quickly.

You'll also want to ensure stability of power supply, when running benchtop experiments with an Arduino this isn't a big issue, bit it can become an issue if transforming power from the mains for a permanent fixture.

  • 2
    There is no reason whatsoever to expect computational load to cause an Arduino to overheat. As has been pointed out in the more fact-based answers, the normal case is to run at full load. If there's a component that may overheat that will be the voltage regulator, but that is primarily a function of input voltage, since it is already running at nearly the highest expected current when doing nothing. Commented Apr 7, 2014 at 16:11
  • @ChrisStratton a Ethernet shield might vary power depending on usage. Also, the Arduino could be in a low power state (for example, sleeping between 12AM and 5AM). Commented Jul 21, 2014 at 2:15

I've never ran an Arduino for that long, but there shouldn't be a problem. One thing to watch out for is the input voltage.

While an Arduino is capable of handling 7-20v as input anything over 12v can overheat after longer periods of time and cause board damage. As a quick recommendation to avoid any overheating of the Arduino I would keep the voltage as close to 7v as possible.


I'd like to mention an issue that doesn't come up very often but can cause long term issues. Memory Leaks and Heap Fragmentation. Almost nobody mallocs in embedded stuff, but if you do, do it right.

  • You beat me to it, +1. Commented May 26, 2014 at 16:14
  • I believe the String class uses malloc and it's quite common.
    – user2973
    Commented Jul 17, 2014 at 17:05
  • Agreed. Especially with a web server, make sure you don't do anything that might fragment memory, like use the String class. However it is easy to avoid that. I have an Arduino running as a web server to let me know if my garage door is closed. That has been running for years.
    – Nick Gammon
    Commented Jul 2, 2015 at 22:56

I built a simple power monitor with my first Arduino. It is powered via USB from a web-server that in turn is powered via a quite substantial battery backup (which does not have notification abilities).

It is also connected to a mobile phone charger plugged into a non-UPS power socket.

So if the power dies the Arduino sends a message to a little program running on the server. The server program in turn sends me an email notification.

It was installed in late September 2013, on the 23rd March 2014 - I got my first email!

So I have not seen a problem (it does not use millis() ) but it does sample the power every 5 seconds.


Is an Arduino capable of running 24/7?

This is a reliability question. In reliability, there are a lots of things to consider.

  1. The software. There are more robust softwares. There are less robust softwares. For instance, for critical applications, dynamic memory allocation is discouraged, as it might lead to memory fragmentation. Unfortunately, Arduino heavily relies on dynamic memory allocation. This problem is exacerbated as most of the Arduino board have a very limited RAM.
  2. The libraries. Many Arduino libraries do have bugs (even those built-in in the Arduino package, as simple as WString!). In normal operation, such bugs may not appear at all. However, you can't hope that "everything will be fine" and that "the user" (or subsystem) will act as predicted. Libraries could also have their limits (i.e. not properly bugs). For instance, many users already cited the millis() function, which resets after 50 days. This, if not handled correctly, might lead to severe bugs.
  3. The reliability of the hardware (not even talking about cheap Arduino clones...). Here a new class of subquestions opens. I will cite only a very limited subset.
    • Are the Arduino Boards designed for reliability? (e.g. what's the
      reliability of the used capacitors? and other components?)
    • Robustness against EMI ? I wouldn't rely on that: most of Arduino boards have just two layers, and lack of a proper ground/power plane.
    • EEPROM (this is both software and hardware). Is your software using the EEPROM? Is implementing some algorithm to prevent cycling (repeated write/erase on the same cells)?
    • Flash memory retention time. Retention time decreases with temperature, and also with the number of programming cycles.
    • Ionizing radiation. Yes, even if the probability is VERY low, at least at sea level, the probability of radiation-induced single-event upset is not zero, and it adequate countermeasures should be taken (especially taken into consideration that the RAM has no hardware error detection) in critical applications.
    • The quality of the power supply.
    • The operating environment. A 25-°C controlled environment, or in a black box over the roof (70°C under the sun in summer)? The higher the temperature, the faster all the degradation mechanisms.
    • ...

Still, you should not be surprised if your arduino will work flawlessy for many years. But this does not ensure that every arduino will.

Some countermeasures will increase the reliability:

  • Use the watchdog: it's better to reset a non responsive system, than having a stuck/misbehaving one.
  • Avoid using any library that uses memory allocation.
  • Implement (if you use the EEPROM) an algorithm to preserve it!
  • Good power supply.
  • Avoid harsh evironments (high temperature, high humidity, large and continuous thermal cycles, etc).

It certainly can run 24/7. I either use 5V to the 5V pin, or a 7808 to the Vin pin to offload the vreg. Ideally it would be 6.5V, but I don’t have such supplies. You may want a decoupler cap on 5V though, to soak any minor spikes when powering up your supply.

Any hardware attached which runs at 5V, I feed with a 7805. You can use LM317s or LM350s in lieu of 78XXs, but you’ll need a few resistors for those, perhaps trimpots.

Not the answer you're looking for? Browse other questions tagged or ask your own question.