Uptime Check Scope Creep: Deciding What Your Monitors Should Not Cover
Most small teams start uptime monitoring with a single check against the homepage and then gradually add more. A check for the contact page appears after a complaint, a check for the API appears after an incident, and a check for an old landing page lingers because nobody remembered to remove it. After a year, the monitoring dashboard contains dozens of entries, several of which fail every weekend for reasons nobody can explain. The problem is not that monitoring is too thorough. The problem is that nobody decided what the monitors were for. This article covers a method for choosing which targets deserve a check, how to retire the ones that no longer earn their place, and the questions to ask before adding another.
Start from user outcomes, not URLs
A useful monitor answers a specific question: can a visitor accomplish something important right now? Begin by listing the outcomes your site exists to support. For a small business site these might include reading product information, submitting an inquiry, logging into a customer area, or completing a purchase. For a content site they might include loading an article and reaching the comments. Each outcome usually depends on several URLs, but one or two of them are the real signal.
Writing outcomes first prevents a common trap, where the team monitors whatever URLs are easiest to find in the site menu rather than whatever users actually depend on. A menu link to an old press page may be reachable through a redirect chain that nobody uses, while the form that generates leads sits on a page with no monitor at all. Ask of each candidate target: if this returned an error at three in the morning, would someone lose money, lose data, or lose a conversation they cannot recover? If the answer is no, the target is a candidate for removal or for a lower-priority check.
Separate availability signals from correctness signals
A check that receives a 200 status code proves that something answered. It does not prove the page is correct. A product page can return successfully while showing an empty price table because a dependency failed silently. Teams that treat status codes as the whole story end up with dashboards that are green during real outages.
Consider which failures you are trying to catch. Some are availability failures: the server does not respond, or returns an error page. Others are content failures: the page loads, but a required element is missing or a string that should appear does not. Content checks are more fragile, because a copy edit can trigger a false alarm, so keep them few and tie them to elements that rarely change, such as a navigation landmark or a form field name. Availability checks can be broader but should still be limited to targets that matter.
A practical scope review checklist
Run this review quarterly, or whenever a monitor fires without a clear cause. First, export the full list of active checks with their targets, intervals, and alert recipients. Second, for each target, write one sentence naming the user outcome it protects. If you cannot write that sentence, mark the check for review. Third, look at the last ninety days of alerts for each target. A monitor that fired ten times and led to zero fixes is either measuring something nobody controls or is misconfigured.
Fourth, confirm that every high-value outcome has at least one check. Many teams discover that their login path, checkout path, or contact form has no monitor, even though those are the places where failures cost the most. Fifth, check for duplicates. Two checks against the same page with different intervals often add noise without adding information. Sixth, verify that each check still points to a live target. Retired pages, renamed paths, and staging hostnames left in production monitor lists produce false alarms that train people to ignore the channel.
Finally, record the decision. A short note explaining why a check exists, who owns it, and what action it should trigger keeps the list from drifting back into sprawl. Without that note, the next person to inherit the monitors will face the same question you faced and will likely keep everything out of caution.
Questions to ask before adding a new check
Before adding a monitor, ask who will act on its alerts and what they will do differently because of it. If the answer is vague, the check will produce anxiety rather than response. Ask whether an existing check already covers the failure, perhaps through a more important path that passes through the same dependency. Ask how the target behaves under normal load and whether the check itself will add meaningful traffic. Ask whether the target is stable enough to monitor, since a page that changes weekly will generate work every time it is edited.
Ask also whether a monitor is the right tool at all. A problem with email delivery, for example, may be better detected through bounce reports or a periodic manual test than through an HTTP check on the mail host. Monitoring the wrong layer creates confidence in the wrong thing. Choosing fewer, well-understood checks usually produces better outcomes than a long list that nobody fully trusts.
Keeping the monitor set honest over time
Monitor sets decay. Sites change, teams change, and the reasons for old checks are forgotten. The remedy is not a single cleanup but a habit: each time a site feature is added, removed, or moved, update the monitor list in the same change. Treat monitor configuration as part of the site, reviewed alongside content and code. When a check is retired, record that too, so the history explains why a target disappeared.
A small, deliberate set of checks, each with a named purpose and owner, will catch more real problems than a sprawling list that trains people to ignore alerts. The goal is not to watch everything. It is to watch the few things that, if they broke, would hurt your visitors and your business, and to be able to say clearly why each one is there.