user3: 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?


user37540: Is an Arduino capable of running 24/7?
This is a reliability question. In reliability, there are a lots of things to consider.

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.
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.
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).


user62: 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.

user168: 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.

user949: 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.

user28: 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.

user3004: 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.

user24: 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.

user8: 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.

user13: 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. 


user11: 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.

3: <p>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. </p>

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

<p>My Questions:</p>

<ul>
<li>Will I have any problems leaving the Arduino turned on all the time?</li>
<li>Is there some other Arduino board better recommended for this?</li>
<li>Are there any precautions that I need to heed regarding this?</li>
</ul>
 37540: <p>Is an Arduino capable of running 24/7?</p>

<p>This is a reliability question. In reliability, there are a lots of things to consider.</p>

<ol>
<li>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.</li>
<li>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.</li>
<li>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.

<ul>
<li>Are the Arduino Boards designed for reliability? (e.g. what's the<br>
reliability of the used capacitors? and other components?)</li>
<li>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.</li>
<li>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)?</li>
<li>Flash memory retention time. Retention time decreases with temperature, and also with the number of programming cycles.</li>
<li>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.</li>
<li>The quality of the power supply.</li>
<li>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.</li>
<li>...</li>
</ul></li>
</ol>

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

<p>Some countermeasures will increase the reliability:</p>

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

<p>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.</p>
 168: <p>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.</p>
 949: <p>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).</p>

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

<p>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.</p>

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

<p>So I have not seen a problem (it does not use millis() ) but it does sample the power every 5 seconds.</p>
 28: <p>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.</p>

<p>In addition, keep it well ventilated.</p>

<p>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.</p>

<p>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.</p>
 3004: <p>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.</p>
 24: <p>Running the Arduino 24/7 Shouldn't be a problem.</p>

<p>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. </p>

<p>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.</p>
 8: <p>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.</p>
 13: <p>A couple of things to keep in mind (outside of @Sachleen's mention of <code>millis()</code>): </p>

<ul>
<li><p>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. </p></li>
<li><p>If your code uses <a href="http://arduino.cc/en/Reference/EEPROMWrite" rel="noreferrer"><code>EEPROM.write()</code></a>, be aware that the EEPROM in your Uno's ATmega328P is only rated for 100,000 writes. </p></li>
</ul>
 11: <p>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 <code>millis()</code>.</p>

<p>From the <a href="http://arduino.cc/en/Reference/millis">Arduino docs on millis</a>:</p>

<blockquote>
  <p>This number will overflow (go back to zero), after approximately 50 days.</p>
</blockquote>

<p>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.</p>
