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.