mirror of
https://github.com/louislam/uptime-kuma.git
synced 2026-03-02 22:57:00 -05:00
Add numeric history to monitors #4231
Labels
No labels
A:accessibility
A:api
A:cert-expiry
A:core
A:dashboard
A:deployment
A:documentation
A:domain expiry
A:incidents
A:maintenance
A:metrics
A:monitor
A:notifications
A:reports
A:settings
A:status-page
A:ui/ux
A:user-management
Stale
ai-slop
blocked
blocked-upstream
bug
cannot-reproduce
dependencies
discussion
duplicate
feature-request
feature-request
good first issue
hacktoberfest
help
help wanted
house keeping
invalid
invalid-format
invalid-format
question
releaseblocker 🚨
security
spam
type:enhance-existing
type:new
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/uptime-kuma#4231
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @cafciel on GitHub (Jul 31, 2025).
📑 I have found these related issues/pull requests
I have looked but didn't find similar requests, except for changes to the response time graph.
🏷️ Feature Request Type
Other
🔖 Feature description
I wouldn't say this is a change on an existing monitor per se, not tagging this request type yet, as this is more a principle feature.
Add the possibility to record the numeric values of monitors and show them in a diagram similar to the response times.
✔️ Solution
Whenever a numeric value is received in a monitor, save that value with its timestamp and the according monitor in itS own table in the DB. When the details of a monitor are opened and there are entries for this monitor in the "numeric value history table" show a graph of that numeric value simmilar to the response time graph.
Since the response time graph is limited to the same timeframe as the status bar - and it makes sense to also define the value history graph this way - additional features could be:
❓ Alternatives
No real alternatives other then using another monitoring tool that supports this, I guess...
📝 Additional Context
checking via SNMP or JSON values the history of that value may be very interesting e.g. monitor RAM of a machine and only knowing it's above the threshold I set, but not knowing whether it gradually rose to that level or suddenly spiked above it is a lack of information that may be crucial.
Since those values are already collected and compared, I guess it's "only" another table to be created/filled and visualized.