skip to content
ryu

Extending Uptime Kuma: 90-day heartbeats, a Slack command, and shipping a fork

Getting an unmerged feature into production, adding a Slack /incident command, and open-sourcing the result as a clean fork.

1 min read

I run status.omnidim.io on Uptime Kuma. Its heartbeat bars only showed a short history, but I wanted 90 days at a glance. The configurable range was not in a stable release. It only existed in an unmerged draft PR (#5916).

So instead of waiting for it to land, I built a custom image from the fork and shipped it.

The 90-day range#

The feature adds a range selector, from auto and 6h up to 365 days, and buckets heartbeat data so the bar stays readable over a longer window. The page aggregates data into a fixed number of buckets instead of drawing every heartbeat. Once I had a custom image, I could enable it with one stored value per status page.

A Slack /incident command#

While I was in there, I added something I’d wanted for a while: posting incidents to the status page straight from Slack.

/incident Backend is slow | investigating | eta 2h | warning

It verifies Slack’s request signature (HMAC, with a replay window), parses the title, details, ETA, and severity, and pins the incident to the page. /incident resolve clears it. No dashboard round-trip when something’s on fire, which is exactly when you don’t want one.

There’s also a small bulk-add script for creating a batch of HTTP monitors from a JSON file, idempotent on name, so standing up monitoring for a fleet of services isn’t a click-fest.

Open-sourcing it properly#

I published the whole thing as uptime-kuma-extended, MIT, with attribution to upstream and to the PR author whose work the range feature is built on.

If you want a longer heartbeat history or a Slack incident hook on your own Uptime Kuma, the repo is there to fork.