OK - I tend to design high value low volume boards so my view of this is biased. I like to sprinkle a lot of LEDs around my boards. One (red) LED for every power voltage on the board. Multiple s/w driven LEDs that show different execution paths in action. LEDs on communications ports, CAN, USART, USB etc so I can see when they are active.


  • I can see whether a board is operating approximately OK at a glance.
  • Ditto with service engineers in the field.


  • They cost money in high volume manufacturing.
  • They take up board space.
  • There may also be power constraints.

What other considerations exist?

  • 9
    \$\begingroup\$ An approach I've seen often is to put those LEDs only on the first run, all successive batches have the LEDs removed. This won't fix your 2nd and 3rd con, but it helps with the 1st and with the UX problems generated by too many LEDs. Would such an approach work for you? \$\endgroup\$
    – Mast
    Commented Aug 14, 2020 at 6:20
  • 1
    \$\begingroup\$ @Mast I have been asked too many times "how do I know the board is working". These days I say something along the lines of "If the blue light is flashing it is probably OK". In the particular product to which this refers, finding reliable coax cables is a far bigger problem \$\endgroup\$ Commented Aug 14, 2020 at 9:51
  • \$\begingroup\$ So keep that one LED that's useful as a sign of overall-working, and ditch the rest in production versions of boards? \$\endgroup\$ Commented Aug 14, 2020 at 19:24
  • 1
    \$\begingroup\$ One or more 7-segment displays is also a good option. These are quite common in industrial and HVAC equipment. \$\endgroup\$ Commented Aug 15, 2020 at 9:35
  • 2
    \$\begingroup\$ You can't add LED's to high volume production boards unless they are part of the actual customer UI. It is just throwing away money. You can put LED's on test fixtures though. And it is fine to keep the LED's in the schematic and layout. Just don't install them in production. When the "customers" are internal developers at your own company (proto builds) the LED's can be extremely useful. But once the customers are retail purchasers, all unused LED's have to go. \$\endgroup\$
    – user57037
    Commented Aug 18, 2020 at 7:36

8 Answers 8



  • LEDs can be distracting or outright annoying, especially if used with too high a brightness (modern I_f=20 mA LEDs when actually driven with that current, especially when blue, are blindingly bright wenn one looks too closely at them)
  • Information overload: if there's too many LEDs, how can you see, without searching the silkscreen or a manual, which means what. Where's the benefit of having an easy to read LED if you don't know which LED to read?
    • I'd go with something like: as soon as you have more LEDs than you can mentally connect to their meaning after a week of not working on the board, more LEDs have diminishing returns – if you need to consult your design documentation to know which LED means what, a simple test point + multimeter might not be much worse
    • If the state of your board is complex (i.e. there's many bits – LED on/off – of status), and might be relevant during operation, not just during prototype testing, maybe a board management IC would be wise, i.e. a microcontroller with ADC channels, GPIOs (not only to sense, but also to do things like resetting stuff, or controlling fans, beepers), and a serial port. Maybe even with an OLED display or something. Often, these same microcontrollers fulfill the role of power sequencer, temperature monitor and watchdog.
      Sounds like more development work to me, but then again, you sound like you're doing more than one board per year, so maybe putting together a simple firmware once that does what you need is wise, and then throwing the same microcontroller on every board, no matter how simple (personal advise: go for a microcontroller that has USB; your laptop-wielding field engineer (so: most likely you) will like that).
      Options range from a few lines of C for your own minimal firmware to using the Embedded Controller Firmware for Chromebooks. I'd not cheap out on the microcontroller too much and avoid going for the 8 bitters – a cheap STM32 ARM would do, for example, and really has the nicer development workflow if you're nowhere near caring for latency in the sub-microseconds.
  • aside from power constraints e.g. of driving digital logic, overall power usage
  • potentially: assume you have some reference voltage rail, or other low-current supply rail (say, a low-speed opamp driving a weak load at < 0.1 mA average). You might need to redesign your supply to suit the much higher LED load, or add complex (and thus, new source of failure) means of buffering (e.g. NPNs, digital gates) to drive the LED.


  • Looks: A board that has 50 green LEDs turn on, partially sequentially, after powerup is bound to impress your customer
  • Human Observability: Of course, even if it's confusingly many, having an LED is still worst case as good as having none.
  • Machine Observability: another LED, simply taped to the LED of interest, on a constant current source, makes an excellent oscilloscope / ADC input
  • More Observability: OpenCV is relatively easy. Add a QR code to two or three corners of your board, scan for that in a camera picture, use the result to unskew the image, and then use a fixed mask to lazily monitor a board in a lab, while working from home.
  • 3
    \$\begingroup\$ Re: power rail and firmware boot LEDs: the old bar displays (from hifi stereos of the 1980s) could be a good idea ("the lower two bars are on, the third is off, the fourth to seventh are on, the eighth is flashing"); reduces the potential for confusing you while investigating another fault while you debug your prototype. Problem is that you need to route the LED signals from the different rails to a central point. \$\endgroup\$ Commented Aug 13, 2020 at 10:00
  • 4
    \$\begingroup\$ Re: LEDs used for fault debugging: idea, but I've never tried this: if you're activating these mostly from firmware, anyways, consider having a (switch-disableable) speaker on board, and consider letting the firmware bitbang out the fault information as 2-FSK (say, a 500 Hz and a 700 Hz tone) after a preamble tone sequence. Humans are fairly good at recognizing tones, and an audio FSK receiver is quickly drafted e.g. in GNU Radio. Service could even ask to flip the switch, and send an audio recording. \$\endgroup\$ Commented Aug 13, 2020 at 10:05
  • 3
    \$\begingroup\$ +1 for distracting. I've refused to purchase products specifically because of bright LEDs, and your definition of bright (in the equatorial sun where you apparently test your products) is not the same as mine (in the dark room where I'm trying to sleep). \$\endgroup\$ Commented Aug 14, 2020 at 1:22
  • 2
    \$\begingroup\$ @chrylis-cautiouslyoptimistic- I've put a layer or two of masking tape over the blue power and HD activity lights on my computer case. Still visible but attenuates it to a reasonable brightness. IDK what was wrong with red LEDs, though; much more comfortable on the eye in older computer cases. \$\endgroup\$ Commented Aug 14, 2020 at 19:27
  • 1
    \$\begingroup\$ @MisterMystère LEDs are also photodiodes. A LED in strong reverse bias, with a couple-kΩ-resistor in series, over which you measure the voltage with an oscilloscope \$\endgroup\$ Commented Sep 9, 2020 at 22:49

In addition to what's already been said:


  • Relatively cheap and easy to implement compared to displays, serial debug interfaces etc. You don't need any deeper software or electronics knowledge to design in a LED, just a bit of Ohm's law.

  • High availability and lots of 2nd source on the market. If your favourite LED company can't deliver in time, it is very easy to find an alternative.


  • Roughly 8% of all men and 0.5% of all women are "color blind", which most commonly manifests itself as problems distinguishing between red and green. Which also happens to be the two most common LED colors.

    This can be especially problematic if you use different colors on the same spot (RGB etc) to indicate different product status. If you ask a customer over phone what color they see, there's a pretty big chance that you get an incorrect answer, particularly so if the products are designed for a traditionally male dominated industry (such as electronics).

  • Light pollution. In products with IR sensors, photocouplers etc, LED light might cause "optical noise".

  • Polarity problems during assembly. As a rule of thumb, components with polarity will eventually get mounted backwards during assembly. Someone loads the pick & place wrong or misunderstands the component placement drawings etc. This is a rather common quality problem in my experience, particularly when it comes to LEDs and tantalum caps. Ultimately this is a production quality issue, but a designer who has the option not to pick components with polarity reduces the number of things that can go wrong.

  • Sensitive components. LEDs are among the most sensitive parts during SMD assembly, and may not survive an oven several times during assembly. Particularly so if you picked some cheap brand.

  • MCU source/sink current budget. It is most often preferable to drive LEDs directly from MCU pins, since it saves you from external circuits and complexity. Most designs hopefully take the source/sink ability of the individual pins in account, but it is common to forget the total source/sink capacity of the chip as whole.

    Imagine that you have a lot of different LEDs that indicate various states in your product, then suddenly during some conditions you experience an unexplained MCU latch-up or reset. The first thing you'll suspect is an application problem in "state x", because the error only occurs when the LEDs for that state are lit. That sends you trouble-shooting in the completely wrong direction, since the actual problem isn't your application logic but the LEDs themselves.

Pro + Con:

  • PWM characteristics. If you hook a LED to a PWM, a serial bus or similar, the human eye is too slow to catch flickering - the LED may appear as constantly lit. This enables various tricks with power saving, multiplexing & color mixing between different LEDs.

    But it also makes it hard to distinguish between for example idle high and operational modes of a serial bus. At best you end up with "how bright does it shine" which is very subjective and not something you want to ask your customer over phone during trouble-shooting. "Umm... it shines quite a bit!"

  • 9
    \$\begingroup\$ And these are not some theoretical scenarios - all of the above are anecdotes of things that I have experienced at some point in my career. \$\endgroup\$
    – Lundin
    Commented Aug 13, 2020 at 11:43
  • 1
    \$\begingroup\$ Good point about the color blind thing - I shall bear that in mind \$\endgroup\$ Commented Aug 13, 2020 at 12:42
  • \$\begingroup\$ Very good point about the colorblindness, I always make my charts use yellow->green->violet linear brightness scales rather than the common green -> red \$\endgroup\$ Commented Aug 14, 2020 at 7:55
  • \$\begingroup\$ I find some yellow and green LEDs to be pretty similar. Personally, I prefer the high voltage / short wavelength (2.5 V) green LEDs over the old style (2.1 V). \$\endgroup\$
    – Oskar Skog
    Commented Aug 14, 2020 at 15:50
  • \$\begingroup\$ PWM gives you more options though: I needed a multi-status signal down 1 wire+ground: flickering dimly (10Hz IIRC - limited users, none with epilepsy)=polling, bright flash=active, steady dim=holdoff, nothing=no power. On powerup it could pass through all these states; so far I haven't bothered butthat would allow the user to calibrate their expectations of dim and bright. It's pretty obvious. \$\endgroup\$
    – Chris H
    Commented Aug 14, 2020 at 17:00

Too many indicators can lead to confusion from the user side :

Too many indicators

Image link

The indicators you have on your board seem to be very numerous and are useful only for a maintenance engineer. I don't know what is the architecture of your boards but probably it is better to use software checks or hardware test loop for the maintenance in case of issues :

Test loops

Image link

  • 4
    \$\begingroup\$ The LEDs are not really for the user, although we have asked a user question such as "Are there 5 red lights on the board and one that is flashing blue" before we send a service guy. In that specific case it generally means the board is working and the fault elsewhere \$\endgroup\$ Commented Aug 13, 2020 at 9:44
  • 1
    \$\begingroup\$ Genorme - Welcome :-) FYI, as required by this site rule, when you include something in an answer (e.g. photo, image or text) which isn't your own original work, you need to properly reference (cite) it. Those images seem to have come from elsewhere, so in order to comply with that rule, can you edit your answer and add a link back to the specific, original source web page for each image, please? Thanks :-) \$\endgroup\$
    – SamGibson
    Commented Aug 13, 2020 at 13:17

Just some 'personal brainstorming':

Pros (see comment DarrenW):

  • The time saved by a technician or other design engineers by not having to hook up JTAG or poke around with a scope probe (because of the LEDs) adds up.


  • Longer design time: although mostly fairly easy to add a LED, it cost time.
  • Reduced power: you already mentioned it, but probably you mean the (micro)Amperes the LED itself is using is deducted from the total. However, also by using a LED, the current is reduced from the original path (unless e.g. a transistor is used), so it affects the current also of the area 'around' the LED.
  • Added/changed GND return paths: as each LED has a return path, could affect e.g. analog (parts of) PCB boards.
  • CPU pin usage: when using a software controlled LED, it cost a pin, or a multiplexer output.
  • Board space: already mentioned by you, however also take the description text next to each LED into account.
  • 1
    \$\begingroup\$ The longer design time is near trivial for many types of products. The time saved by a technician or other design engineers by not having to hook up JTAG or poke around with a scope probe adds up. I know from experience. \$\endgroup\$
    – DarenW
    Commented Aug 18, 2020 at 3:29
  • \$\begingroup\$ @DarenW I fully agree, I put the longer design time specifically as in this case it does not add a feature (something useful for a client), I will add the JTAG/scope remark. Thanks \$\endgroup\$ Commented Aug 18, 2020 at 7:28

LEDs are useful for basic diagnostics such as checking power is on and all rails have come up, or for indicating certain activity such as communication or connection status.

However for more detailed diagnostics there are better options. If you have a microcontroller you can add a UART interface. No harm in having debug messages on your production boards most of the time. JTAG is another good option.

For low volume stuff you could also add a small display. Miniature OLED displays are cheap and easy to interface with, and can display a lot more information in a more readable format.


I have built boards run by PIC MPUs and added just a few LEDs to indicate power and MPU status, and a "heart-beat" LED to show that software was not hung up. Add another LED to show links to another board were good.

Still this is judicious use of LEDs. The last thing I wanted was a board to show the chief engineer that looked like a Christmas tree. Instead there was just a row of 8 tiny SMD LEDs, red and green, running at 2 mA so they had a soft glow, not bright like spot-lights.

In my mind there are no cons for judicious use of LEDs as crucial condition indicators. One look at a Ethernet hub and solid or blinking LEDs for power and data shows that in small numbers they are very useful. Bi-color and RGB LEDs can present a GO/NO-GO/BUSY status in 1 small LED. LED flashing vs. LED solid color can also imply a higher status level.

  • 3
    \$\begingroup\$ I learned long ago as a young engineer that Management liked seeing flashing lights, as opposed to a bare board allegedly doing something. \$\endgroup\$ Commented Aug 14, 2020 at 9:48
  • \$\begingroup\$ There should probably be a few LED's to show active traffic or processing taking place, but not too many that it becomes distracting. The LED's for those who use it should be informative and nothing more - any more unnecessary LED's (when you could just as easily have a UART interface) will become a hassle to debug. The LED's for Management or for impressing the user would still be there but in one confined space to show that something is actually happening. That's my opinion anyway, having a few LED's in a row is much easier to design on a PCB and to manufacture compared to many LED's \$\endgroup\$
    – QuickishFM
    Commented Aug 14, 2020 at 11:34

Cons: few more things to consider

1- total raise in temperature, LEDs dissipates high amount of heat compared to other devices. This could affect some sensitive devices specially when the board has to be isolated from surroundings, like boards in ROVs or so.

2- more current means more trace width, larger power supply, higher rated components, much bigger board size thus more overall cost.

3- one more important thing to consider, the expected operating time to devices operated by battery will significantly drop down. Some applications requires devices with long battery operating time. Hot kiln alignment as an example which is the major I'm specialized in requires devices that can operate for long periods of time, 3 hours for example and yes 3 hours is too much long enough because temperature in shells in such cases rises to some how near 350 °C. That means you have to depend on devices that can withstand these temperatures and withstand the circumstances until your job has been done.

Shell Average Temperature


1- Nicely looking boards.

2- Attracts attention.

3- Ease of monitoring and troubleshooting.

Conclusion Avoid placing LEDs on boards that are not mandatory. If it has no use then its not worth having to be placed.


If you want to keep the pros and avoid most of the cons, ditch the LEDs and route the signals driving them to a debug connector somewhere. Design a small debug breakout board that can attach to this connector. Put all the LEDs on the breakout board. That way, you only pay for one set of LEDs per technician instead of one per board. You still have the debug option, but you don't have to pay for the extra hardware unless you're actually going to use it. Power the LEDs from the debug board to avoid changing the device's power profile when it's plugged in. You also avoid confusing the end-user since they can no longer see those debug signals that are only meaningful to your technicians.

A breakout board for debugging has other useful advantages, like allowing you to label and organize the LEDs in a more user-friendly layout, and enabling you to add (for instance) a small microcontroller to monitor LED states and report status to a connected PC over USB.

The con here is that routing all those debug signals might be tricky, depending on your current board density.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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