We wanted those clean, Checkmate-style graphs on our public status page. Showing response times and server resources right next to the usual uptime bars. We absolutely did not want to host a whole second monitoring app just to draw a few lines on a screen.
The data was already there
The funny thing is, we realized we were already sitting on all the data we needed. Our Discord bot probes each of our services on a 5-minute heartbeat anyway. The probe was measuring response times on every single request, but then it just threw that number away and only returned a basic "online" or "offline" string. We were literally computing the graph data and deleting it instantly lol.
So, the fix was super lightweight:
- Capture the latency the probe was already measuring instead of dumping it.
- Grab host CPU / RAM / disk info straight from
/proc(just using the Linux stdlib). - Save both metrics right alongside our existing uptime history entries.
- Draw inline-SVG sparklines directly onto the status cards.
Why not just use Uptime Kuma?
Don't get us wrong, tools like Checkmate or Uptime Kuma are awesome, but they're entirely separate applications. They come with their own databases, user auth, and UIs. Since we're running on a shared host, that's just more stuff we'd have to manage and keep secure, plus, it wouldn't match our custom, hand-built frontend design. We already had 90% of the logic written, so why add more clutter?
Our new rule: actually use the data you already have before you go installing a whole new service to collect it.
The stack
| Metric | Source |
|---|---|
| Response time | Existing bot probe (elapsed) |
| CPU / RAM | /proc/stat, /proc/meminfo |
| Disk | shutil.disk_usage |
We ended up with zero new dependencies on the bot, no heavy charting libraries bloated onto the site, and no new background services to manage. Just an honest use of numbers we were already collecting anyway.