Theme status pages (and dashboard?) by defining "base colors" in Appearance setting #3237

Open
opened 2026-02-28 03:22:42 -05:00 by deekerman · 7 comments
Owner

Originally created by @pro-sumer on GitHub (Apr 1, 2024).

Unable to find any related issue.

🏷️ Feature Request Type

Status-page

🔖 Feature description

It would be great if one can configure Uptime Kuma's "base colors" in the web interface, instead of manually overwriting many individual status page elements using CSS.

Bonus: also theme the dashboard this way.

✔️ Solution

Allow the user to define the hex/RGB values for the "base colors" in the Appearance section of Uptime Kuma's settings.

Alternatives

A CSS solution that does not require overwriting many individual status page items would also be good, but unfortunately I don't know how to do that (if this is already possible, a Wiki entry on how to do it would be appreciated).

📝 Additional Context

N/A

Originally created by @pro-sumer on GitHub (Apr 1, 2024). ### 📑 I have found these related issues/pull requests Unable to find any related issue. ### 🏷️ Feature Request Type Status-page ### 🔖 Feature description It would be great if one can configure Uptime Kuma's "base colors" in the web interface, instead of manually overwriting many individual status page elements using CSS. Bonus: also theme the dashboard this way. ### ✔️ Solution Allow the user to define the hex/RGB values for the "base colors" in the Appearance section of Uptime Kuma's settings. ### ❓ Alternatives A CSS solution that does not require overwriting many individual status page items would also be good, but unfortunately I don't know how to do that (if this is already possible, a Wiki entry on how to do it would be appreciated). ### 📝 Additional Context N/A
Author
Owner

@CommanderStorm commented on GitHub (Apr 1, 2024):

Currently, our system works by defining colours in SCSS in src/assets/vars.scss.
This is then used in most places (not quite all, PRs welcome)
The colours are then used at src/assets/app.scss to override the defaults by bootstrap 5.

The problem is that SCSS variables are not changeable at runtime (SCSS is compiled).
One option would be to change these to CSS variables.

I think changes like you did on https://status.prosumer.dev/ are somewhat out of scope.
If somebody has such special requirements, they will be reaching for the CSS guns anyway… => don't see a big payoff of spending lots of effort here..

@CommanderStorm commented on GitHub (Apr 1, 2024): Currently, our system works by defining colours in SCSS in [`src/assets/vars.scss`](https://github.com/louislam/uptime-kuma/blob/master/src/assets/vars.scss). This is then used in most places (not quite all, PRs welcome) The colours are then used at [`src/assets/app.scss`](https://github.com/louislam/uptime-kuma/blob/master/src/assets/app.scss) to override the defaults by [bootstrap 5](https://getbootstrap.com/docs/5.2/getting-started/introduction/). The problem is that SCSS variables are not changeable at runtime (SCSS is compiled). One option would be to change these to [CSS variables](https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_custom_properties). I think changes like you did on https://status.prosumer.dev/ are somewhat out of scope. If somebody has such special requirements, they will be reaching for the CSS guns anyway… => don't see a big payoff of spending lots of effort here..
Author
Owner

@pro-sumer commented on GitHub (Apr 2, 2024):

The problem is that SCSS variables are not changeable at runtime (SCSS is compiled).

That's what I thought. Thanks for confirming.

If somebody has such special requirements, they will be reaching for the CSS guns anyway…

Luckily Uptime Kuma allows custom CSS. Thank you for that option.

@pro-sumer commented on GitHub (Apr 2, 2024): > The problem is that SCSS variables are not changeable at runtime (SCSS is compiled). That's what I thought. Thanks for confirming. > If somebody has such special requirements, they will be reaching for the CSS guns anyway… Luckily Uptime Kuma allows custom CSS. Thank you for that option.
Author
Owner

@chakflying commented on GitHub (Apr 2, 2024):

We should consider moving from scss variables to css variables to allow customization in this way.

@chakflying commented on GitHub (Apr 2, 2024): We should consider moving from scss variables to css variables to allow customization in this way.
Author
Owner

@tayflo commented on GitHub (Feb 25, 2026):

I've just noticed that beats are now drawn by canvas (.heartbeat-canvas) instead of individual elements, and so it seems (but I might be missing something here) it's no longer possible to change their colors with custom CSS (it was possible in version 1.23.17).

@tayflo commented on GitHub (Feb 25, 2026): I've just noticed that beats are now drawn by canvas (`.heartbeat-canvas`) instead of individual elements, and so it seems (but I might be missing something here) it's no longer possible to change their colors with custom CSS (it was possible in version 1.23.17).
Author
Owner

@CommanderStorm commented on GitHub (Feb 25, 2026):

Unfortunate that this broke your usage, we just did not think about this usecase.

You can still overide the colors via the CSS variables --beat-empty-color, ..
github.com/kurama/uptime-kuma@8ad09ccd13

@CommanderStorm commented on GitHub (Feb 25, 2026): Unfortunate that this broke your usage, we just did not think about this usecase. You can still overide the colors via the CSS variables `--beat-empty-color`, .. https://github.com/kurama/uptime-kuma/commit/8ad09ccd13091117ebaef35eaca50a49b453231d
Author
Owner

@tayflo commented on GitHub (Feb 26, 2026):

Very nice, thanks! I've been able to change the colors of the beats on the canvas using a syntax like that:

:root {
  --bs-primary: #fff;
  --bs-warning: #fff;
  --bs-danger: #fff;
  --maintenance: #fff;
  --beat-empty-color: #fff;
}

It's also nice that those values apply broadly, even if sometimes it is required to change the RGB triple instead, for instance for:

.bg-danger {
  background-color: rgba(var(--bs-danger-rgb),var(--bs-bg-opacity)) !important;
}

I'm not quite sure why this is necessary; in practice, I've just seen --bs-bg-opacity set to 1. But I guess this exists to allow for some kind of flexibility.


Even though, I've not been able to change the text color on the tooltip appearing on mouseover. The tooltip disappear dynamically so I've not been able to inspect the element.

And I guess it's unaffected by CSS variables because it's using the SCSS variables.

It's the same for the overall status icon but this one is more easily inspectable.

@tayflo commented on GitHub (Feb 26, 2026): Very nice, thanks! I've been able to change the colors of the beats on the canvas using a syntax like that: ```css :root { --bs-primary: #fff; --bs-warning: #fff; --bs-danger: #fff; --maintenance: #fff; --beat-empty-color: #fff; } ``` It's also nice that those values apply broadly, even if sometimes it is required to change the RGB triple instead, for instance for: ```css .bg-danger { background-color: rgba(var(--bs-danger-rgb),var(--bs-bg-opacity)) !important; } ``` I'm not quite sure why this is necessary; in practice, I've just seen `--bs-bg-opacity` set to 1. But I guess this exists to allow for some kind of flexibility. --- Even though, I've not been able to change the text color on the tooltip appearing on mouseover. The tooltip disappear dynamically so I've not been able to inspect the element. And I guess it's unaffected by CSS variables because it's [using](https://github.com/kurama/uptime-kuma/blob/574d42ca51cd5ed7ad6893aa92ae180dcdae6ca3/src/components/Tooltip.vue#L152-L170) the [SCSS variables](https://github.com/kurama/uptime-kuma/blob/574d42ca51cd5ed7ad6893aa92ae180dcdae6ca3/src/assets/vars.scss). It's the same for the [overall status icon](https://github.com/kurama/uptime-kuma/blob/574d42ca51cd5ed7ad6893aa92ae180dcdae6ca3/src/pages/StatusPage.vue#L1496-L1511) but this one is more easily inspectable.
Author
Owner

@CommanderStorm commented on GitHub (Feb 26, 2026):

Feel free to contribute a code change if you know a better version.

I have been wanting to reduce the extremely high number of custom CSS for a while, but have not come to it.
Changes to html and thus are not something that I consider public api since that is just way too hard to to controll.
If we can move most of those usecases to css variables, that would be much simpler.

@CommanderStorm commented on GitHub (Feb 26, 2026): Feel free to contribute a code change if you know a better version. I have been wanting to reduce the extremely high number of custom CSS for a while, but have not come to it. Changes to html and thus are not something that I consider public api since that is just way too hard to to controll. If we can move most of those usecases to css variables, that would be much simpler.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/uptime-kuma#3237
No description provided.