# Limited choice for status colors
**URL:** https://discourse.nodered.org/t/limited-choice-for-status-colors/100626
**Category:** General
**Created:** [22 March 2026 16:32 UTC](https://discourse.nodered.org/t/limited-choice-for-status-colors/100626 "2026-03-22T16:32:16Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@duaw](https://discourse.nodered.org/u/duaw)
#### Post date: [22 March 2026 16:32 UTC](https://discourse.nodered.org/t/limited-choice-for-status-colors/100626/1 "2026-03-22T16:32:16Z")
Hi!
The documentation says:
> The `fill` property can be: `red`, `green`, `yellow`, `blue` or `grey`
Is there a deeper reason why status colors are limited to these? CSS names would be nice.
Cheers, Uwe
---
### Author:  [@dceejay](https://discourse.nodered.org/u/dceejay)
#### Post date: [22 March 2026 16:52 UTC](https://discourse.nodered.org/t/limited-choice-for-status-colors/100626/2 "2026-03-22T16:52:25Z")
Hi yes, we wanted them to be limited so that hopefully users could use and rely on them consistently, so in general red means error, green means good, etc. and also that people couldn’t theme them and change the colours which may cause confusion.
---
### Author:  [@duaw](https://discourse.nodered.org/u/duaw)
#### Post date: [23 March 2026 08:13 UTC](https://discourse.nodered.org/t/limited-choice-for-status-colors/100626/3 "2026-03-23T08:13:26Z")
The editor evolved heavily during the last years. It has become a powerful means to see what's going on in a flow during development and also when flows run run.
I make copious use of debug nodes and their various status possibilities.
State is lagging behind here. Time to beef it up. `red` , `green` , `yellow` , `blue` and `grey` would still be possible, upward compatible, and well understood – but a wider choice would be appreciated, I think.
No `violet` , no `orange`. I really miss them. Sometimes I have (a) more than 5 states and (b) the color does not help to identify the state.
I did not look in the code but it should not be a big deal. If NR allows some 5 colors then it could easily allow those 140 standard colors.
What do you think, guys & gals?
Cheers, Uwe
---
### Author:  [@dceejay](https://discourse.nodered.org/u/dceejay)
#### Post date: [23 March 2026 08:24 UTC](https://discourse.nodered.org/t/limited-choice-for-status-colors/100626/4 "2026-03-23T08:24:21Z")
I can’t easily tell the difference between ivory and corn silk, so no I think 140 is too many. I could maybe get behind a small extension, maybe adding cyan, magenta, black and white ?
---
### Author:  [@hardillb](https://discourse.nodered.org/u/hardillb)
#### Post date: [23 March 2026 08:42 UTC](https://discourse.nodered.org/t/limited-choice-for-status-colors/100626/5 "2026-03-23T08:42:09Z")
The editor is not meant to be a dashboard
---
### Author:  [@duaw](https://discourse.nodered.org/u/duaw)
#### Post date: [23 March 2026 09:34 UTC](https://discourse.nodered.org/t/limited-choice-for-status-colors/100626/6 "2026-03-23T09:34:24Z")
That would help. Perhaps 16 easily distinguishable standard colors. For example [Web colors - Wikipedia](https://en.wikipedia.org/wiki/Web_colors)
Cheers, Uwe
---
### Author:  [@duaw](https://discourse.nodered.org/u/duaw)
#### Post date: [23 March 2026 09:36 UTC](https://discourse.nodered.org/t/limited-choice-for-status-colors/100626/7 "2026-03-23T09:36:10Z")
No, it is not. But the editor is an invaluable tool to see what's going on during development and bug squashing.
Cheers, Uwe
---
### Author:  [@gregorius](https://discourse.nodered.org/u/gregorius)
#### Post date: [23 March 2026 10:15 UTC](https://discourse.nodered.org/t/limited-choice-for-status-colors/100626/8 "2026-03-23T10:15:18Z")
> [@duaw](#):
>
> going on during development and bug squashing
I second that sentiment. That's probably also why, IMHO, more effort should be put into creating integrated introspection tooling beyond the debug node. But again, those efforts make the editor more of a "dashboard" - dashboard being something implicitly linked to the running system rather than being - as it is now - a static representation of what is happening on the server.
Along these lines, there is an idea of creating a running update of the context --\> [Streaming changes to context (NR5?)](https://discourse.nodered.org/t/streaming-changes-to-context-nr5/100608) Which would also fall under the "dashboard" category.
I would love to be a fly on the wall and find out why all these "dashboard" features aren't being embraced. It makes Node-RED a far better tool for general purpose applications.
Ironically, for me, Node-RED isn't a "dashboard" nor "editor", it's just a fancy vector image editing tool. Unfortunately the shapes are limited to rectangles and lines connecting them but still just an image editing tool (built for the browser using jQuery).
---
### Author:  [@knolleary](https://discourse.nodered.org/u/knolleary)
#### Post date: [23 March 2026 10:29 UTC](https://discourse.nodered.org/t/limited-choice-for-status-colors/100626/9 "2026-03-23T10:29:57Z")
> [@gregorius](#):
>
> I would love to be a fly on the wall and find out why all these "dashboard" features aren't being embraced. It makes Node-RED a far better tool for general purpose applications.
The whole 'the editor is not a dashboard' is an outdated sentiment and not the view I take these days. It too readily dismisses the valid feedback around what the editor could do.
On the other hand, I can only embrace so many pieces of work at once. With a lack of other people actively getting involved, then it comes largely down to what order I pick things of the list.
> [@gregorius](#):
>
> Along these lines, there is an idea of creating a running update of the context --\> [Streaming changes to context (NR5?)](https://discourse.nodered.org/t/streaming-changes-to-context-nr5/100608)
I don't want this thread to spawn into a wider discussion, but for that one specifically, I have already outlined the hard technical problem that stands in the way; the underlying API doesn't support the sort of events needed to do that monitoring. Finding a way to update the API in way that doesn't break users with custom context stores is not trivial.
---
### Author:  [@hazymat](https://discourse.nodered.org/u/hazymat)
#### Post date: [23 March 2026 10:30 UTC](https://discourse.nodered.org/t/limited-choice-for-status-colors/100626/10 "2026-03-23T10:30:14Z")
> [@hardillb](#):
>
> The editor is not meant to be a dashboard
This is a really interesting point, because it raises the question "what is the purpose of dashboard".
In my world, the dashboard is for the end-user, and the editor is for the administrator. (End user in my case being family, but could be "operational staff" etc.)
In that case, would you really want the dashboard to be the place where you keep an eye on context data?
---
### Author:  [@gregorius](https://discourse.nodered.org/u/gregorius)
#### Post date: [23 March 2026 10:45 UTC](https://discourse.nodered.org/t/limited-choice-for-status-colors/100626/11 "2026-03-23T10:45:38Z")
> [@hazymat](#):
>
> because it raises the question "what is the purpose of dashboard"
I think we need different terminology hence my phrasing:
> [@gregorius](#):
>
> more of a "dashboard" - dashboard being something implicitly linked to the running system rather than being - as it is now - a static representation of what is happening on the server.
"Dashboard" here is the wrong term. The "dashboard" is definitely a read-only, gauge-filled indication of the health of the overall system. The editor being implicitly linked to what is going on in the server is something completely different and definitely isn't a "dashboard".
So there are really three representations of NodeRED here: dashboard as in gauges, editor as in admin making system changes and "debugging"/"introspection" view of the running system in terms and related to the deployed flow, e.g. visual message tracing through the flow.
> [@hazymat](#):
>
> want the dashboard to be the place where you keep an eye on context data
I would disagreed. The context data might (optionally) be visually represented in the dashboard as a gauge (also giving that data a semantic meaning). But in the editor (required) as your screenshot - i.e. context data is something important - potentially - to both views but should be displayed as is proper for the view and target audience. I.e. watching the context being modified directly in the editor is something an admin should understand, but it shouldn't be the view that a dashboard viewer should be shown.
---
### Author:  [@dceejay](https://discourse.nodered.org/u/dceejay)
#### Post date: [23 March 2026 12:31 UTC](https://discourse.nodered.org/t/limited-choice-for-status-colors/100626/12 "2026-03-23T12:31:16Z")
> [@knolleary](#):
>
> I don't want this thread to spawn into a wider discussion,
….. indeed
---
### Author:  [@duaw](https://discourse.nodered.org/u/duaw)
#### Post date: [23 March 2026 12:43 UTC](https://discourse.nodered.org/t/limited-choice-for-status-colors/100626/13 "2026-03-23T12:43:14Z")
I totally agree. I only had the topic in mind.
---
### Author:  [@softy2k](https://discourse.nodered.org/u/softy2k)
#### Post date: [23 March 2026 18:45 UTC](https://discourse.nodered.org/t/limited-choice-for-status-colors/100626/14 "2026-03-23T18:45:45Z")
Probably so. But, out of necessity, I use it both as a dashboard and for debugging.
I use node.status a lot (color and text), on a few servers, used in a (quite) large factory.
The Christmas tree with all the colored lights is a small child next to my editor.
A few colors would help me (maximum 16, I'm not a painter)
---
### Author:  [@Trying\_to\_learn](https://discourse.nodered.org/u/Trying_to_learn)
#### Post date: [24 March 2026 03:46 UTC](https://discourse.nodered.org/t/limited-choice-for-status-colors/100626/15 "2026-03-24T03:46:39Z")
Just in passing I'll put in my two cents worth.
I do hear what you are saying and I prefer `lime` to `green`. 😉
In such situations where I need to see/know more than the colours available I use a `function` node and a `node.status({})` line.
Then include text to indicate what's going on.
That way I can look at the node and see the `status` of it and _know_ the state of things.
This presents **limitless** options and though not as colourful as the alternate, is handy.
I guess - and I have kind of done this - colour coded the messages too sometimes.
Obviously `red` **something is wrong**
`green` all good
and the other `3` for anything in between those two.
P.S.
I also have a little _node_ that @hotNipi helped me make a long time ago.
It is a 1 x1 square on the `dashboard` that presents a 3 x 3 grid of small squares that can have ANY COLOUR you want in/on them.
If interested I'll post the code.
(Sorry, it is `2` nodes. One `template` node and one `function` node.)
---
### Author:  [@ThingsTinkerer](https://discourse.nodered.org/u/ThingsTinkerer)
#### Post date: [25 March 2026 12:59 UTC](https://discourse.nodered.org/t/limited-choice-for-status-colors/100626/16 "2026-03-25T12:59:48Z")
> [@dceejay](#):
>
> ifference between ivory and corn silk, so no I think 140 is too many. I could maybe get behind a small extension, maybe adding
I know my team mates are using editor as dashboard, in fact they moved away from dedicated dashboards 😃
---
### Author:  [@dougle03](https://discourse.nodered.org/u/dougle03)
#### Post date: [27 March 2026 19:26 UTC](https://discourse.nodered.org/t/limited-choice-for-status-colors/100626/17 "2026-03-27T19:26:51Z")
> [@knolleary](#):
>
> The whole 'the editor is not a dashboard' is an outdated sentiment and not the view I take these days. It too readily dismisses the valid feedback around what the editor could do.
Fully agree, I make extensive use of `node.status` on functions etc. I've modified the stoptimer to show `remaining time` rather than `running`, makes it a lot easier to see in real-time what's happening.
Colours bother me less, but a few additional `visual` nodes would be amazing during development; like a `text box` node that functions like a floating debug but with multiple lines, something that could be dragged into the ui and fed in the same way a debug node is fed... Perhaps I'll write one, but last time I looked there were limitations to this that broke the current node standard GUI elements etc... For the moment I store output to an array and then show that in a `table` on the dashboard, but it's a cludgy work-around for sure and gets messy with additional nodes to handle storing to context, clearing the context etc....
If I'm working on a complicated flow, it would be great to have a handful of `floating` debug windows, one at each stage of the flow to monitor what's passing from node to node... Sure the main debug panel is there, but it's sequential and takes a bit of scrolling etc to really see what's going on. Aligning the floating panels would be a real bonus to see the messages side by side...
---
### Author:  [@dceejay](https://discourse.nodered.org/u/dceejay)
#### Post date: [27 March 2026 22:01 UTC](https://discourse.nodered.org/t/limited-choice-for-status-colors/100626/18 "2026-03-27T22:01:44Z")
> [@dougle03](#):
>
> floating debug but with multiple lines,
maybe [node-red-contrib-image-output (node) - Node-RED](https://flows.nodered.org/node/node-red-contrib-image-output) could inspire you
---
### Author:  [@dougle03](https://discourse.nodered.org/u/dougle03)
#### Post date: [27 March 2026 22:06 UTC](https://discourse.nodered.org/t/limited-choice-for-status-colors/100626/19 "2026-03-27T22:06:18Z")
> [@dceejay](#):
>
> could inspire you
That's a good start. But i'd need to completely refactor it to cope with multiple lines of text etc...
---
### Author:  [@dceejay](https://discourse.nodered.org/u/dceejay)
#### Post date: [27 March 2026 22:07 UTC](https://discourse.nodered.org/t/limited-choice-for-status-colors/100626/20 "2026-03-27T22:07:49Z")
indeed - but it's the principle you want 🙂 exercise for the weekend sir. (and a glass of wine), or a chat with claude.ai
[Next page](https://discourse.nodered.org/t/limited-choice-for-status-colors/100626.md?page=2)