Uptime Kuma Tips: Recent Reddit Q&A

A collection of recent Uptime Kuma questions from Reddit, covering monitor organization, basic JSON monitoring, and advanced monitoring solutions.

Hey guys! I've been active on Reddit recently, helping out fellow Uptime Kuma users with various questions. I wanted to collect some of these discussions here as they might be helpful for others setting up their monitoring.

Understanding Monitor Organization with Groups

One user asked about the fundamentals of how groups work in Uptime Kuma. Groups are primarily organizational tools that help you manage and understand your monitoring setup more effectively. In my environment, I use groups to categorize monitors into logical sections like Infrastructure, Security & Network, Media, and Applications. This makes it much easier to manage larger deployments - instead of scanning through 70+ individual monitors, I can quickly identify which area needs attention.

When you first create a group, you might see a "Pending" status. This initial state appears before any monitors are added to the group, and some users find it confusing. Once you add monitors to the group, the status will reflect the collective state of its members, giving you a quick overview of that section of your infrastructure.

Basic JSON Value Monitoring

Another user asked about monitoring JSON values and getting notifications when they fall below specific thresholds. Uptime Kuma's JSON monitor is perfect for this use case. Here's a working example:

  1. Create a new monitor and select "JSON" as the type
  2. Set your endpoint URL
  3. In the JSON query field, use the path to your value (e.g., data.value for a JSON structure like {"data": {"value": 42}})
  4. Enable "Check Value"
  5. Set your threshold in "Expected Value" (e.g., 42)
  6. Choose your comparison operator (e.g., >= for checking if the value stays above a threshold)

This setup will alert you whenever the monitored value crosses your defined threshold, making it great for monitoring metrics like disk space, user counts, or any other numerical values exposed through JSON APIs.

Advanced JSON Monitoring: Tracking Sequential Values

A more complex scenario came up where a user needed to monitor a continuously increasing value (boot time) to detect system resets. This required comparing each value against the previous check - something beyond Uptime Kuma's built-in capabilities. Here's the custom solution I developed using Python and Uptime Kuma's push monitoring:

#!/usr/bin/env python3
import requests
import os

URL = "http://your-device-endpoint/seconds_since_boot"
PUSH_URL_SUCCESS = "https://uptime-kuma.yourserver.com/api/push/yourpushid?status=up"
PUSH_URL_FAIL = "https://uptime-kuma.yourserver.com/api/push/yourpushid?status=down"
STATE_FILE = "/tmp/previous_value.txt"

def get_current_value():
    resp = requests.get(URL, timeout=5)
    resp.raise_for_status()
    return int(resp.text.strip())

def get_previous_value():
    if os.path.exists(STATE_FILE):
        with open(STATE_FILE, "r") as f:
            return int(f.read().strip())
    return None

def save_value(val):
    with open(STATE_FILE, "w") as f:
        f.write(str(val))

def send_push(url):
    requests.get(url, timeout=5)

if __name__ == "__main__":
    current = get_current_value()
    prev = get_previous_value()

    if prev is not None:
        if current < prev:
            # Value has gone down, indicating a reset
            send_push(PUSH_URL_FAIL)
        else:
            send_push(PUSH_URL_SUCCESS)
    else:
        # No previous value found, just record current and send success for now
        send_push(PUSH_URL_SUCCESS)

    save_value(current)

To automate this check, you'll need these systemd unit files:

# /etc/systemd/system/value-check.service
[Unit]
Description=Check device uptime value and push to Uptime Kuma

[Service]
Type=oneshot
ExecStart=/usr/bin/python3 /path/to/your_script.py

# /etc/systemd/system/value-check.timer
[Unit]
Description=Run value-check.service every minute

[Timer]
OnBootSec=30
OnUnitActiveSec=60

[Install]
WantedBy=timers.target

After creating these files, enable and start the timer:

sudo systemctl daemon-reload
sudo systemctl enable --now value-check.timer

This solution runs every minute, comparing the current value against the previous one and updating Uptime Kuma accordingly. While it's more involved than using a built-in monitor, it provides complete control over the comparison logic.

Looking Forward

These are just a few of the interesting discussions happening in the Uptime Kuma community. I'll try to keep sharing useful tips and solutions as I come across them. If you have any specific questions or scenarios you'd like me to cover, feel free to reach out!

Found this helpful? Check out my other homelab posts for more monitoring tips and configurations.