Two Kinds of "Should We Add This Tool"

A live status widget needed uptime and latency data, and the site's own listed skills include Prometheus and Grafana — a real, tempting reason to reach for them right there. Standing up a metrics stack to answer one boolean and one number would have been solving a much bigger problem than the one on the table.

The question that separated the two cases

"Would this tool help" is almost always yes, for almost any tool, on almost any project — that question is too permissive to guide a decision. The question that actually matters is narrower: does this specific task need what only this tool provides, or would a much smaller thing do. A single uptime percentage and a ping value needed a monitor and a status-page API, which is what Uptime Kuma already is; it didn't need a time-series database and a dashboarding layer.

Where the line actually got drawn

Prometheus and Grafana stayed out of this task, not out of the project permanently — they're a legitimate future addition if something ever needs real time-series metrics (CPU, memory, request latency histograms) rather than a single current-status snapshot. Scoping today's task correctly didn't mean rejecting the bigger stack, it meant recognizing that today's task was never big enough to need it.

The actual discipline

Every unused entry on a skills list is a small, standing invitation to reach for it whether or not the task in front of you calls for it. The useful habit isn't resisting good tools — it's asking what the task specifically requires before asking what's available, so the second list doesn't quietly write the first one.