The task that is always scheduled for after the incident
Monitoring is the classic second-priority task: obviously worth doing, never urgent, and permanently one sprint away. It gets promoted to urgent exactly once — in the hour after an outage that ran for a day before anyone noticed. The work itself is small; what makes it expensive is the timing, because the version of you that finally sets it up has already paid for it.
The asymmetry is worth stating plainly. Setting up a first monitor costs about fifteen minutes and, on a free plan, nothing. Not having one costs an unbounded amount, once, at a time you do not choose. There is no third option where the failure politely waits until the monitoring is ready.
History cannot be backfilled
The reason "later" is more expensive than it looks is that monitoring produces a record, and records only start when you start them. You cannot ask a monitoring service what your uptime was last quarter if it was not watching last quarter. The first useful outputs — a real availability number, a normal-looking latency range, a sense of which endpoint is quietly getting slower — need weeks of collected data behind them.
That matters the first time somebody asks you to stand behind a number: a customer requesting an uptime figure, a security questionnaire, a renewal conversation, or your own team deciding whether an endpoint has regressed. Retention windows differ by plan — PageLantern keeps 30 days of history on Free, 90 days on Starter, and a year on Team — but every one of them starts counting from the day you turn a monitor on, not from the day you need the answer.
Expiry monitoring has the same property in a sharper form. A certificate warning is only useful with enough lead time to fix a failed renewal during business hours, so a monitor added the week a certificate lapses is a monitor that arrived too late to do its job.
The first fifteen minutes buy most of the value
You do not need a monitoring strategy to begin. One check on the page whose failure would matter most, asserting on the status code and a piece of text that only appears when the page really rendered, plus one alert channel your team already watches, covers the large majority of the outages that actually hurt. Everything else is refinement you can do later, with the benefit of real data.
Sensible defaults do the rest. In PageLantern an incident opens after two consecutive failed checks and resolves on the first successful one, and HTTP, HTTPS, API, and content checks are confirmed from a second region before an incident opens — so a single dropped packet or one network blip near a prober does not page anyone. Alerts can go to email, Slack, Microsoft Teams, Discord, PagerDuty, a generic webhook, or SMS on paid plans; the right first choice is simply whichever one a human definitely reads.
Cost is not a reason to wait
The usual budget objection does not survive contact with the numbers. PageLantern's Free plan covers 15 monitors at 5-minute checks, with HTTP, TCP, SSL, domain, and heartbeat checks, one hosted status page, one alert channel, and 30 days of history, with no card required — it asks only that you sign in every 45 days to keep monitoring active, after three email reminders, and pausing keeps your monitors and settings in place.
That is enough to cover a small site properly rather than partially. If you outgrow it, paid plans add faster checks, browser checks, longer history, more channels, and team roles — but the decision to start does not depend on any of that, and it is easier to justify an upgrade once you have a month of your own data arguing for it.
A sensible order to expand in
Add monitors in the order that failures cost you money. First, the pages that take orders or sign-ups. Second, certificate and domain expiry, because both take the entire site down on a known date and give no other warning. Third, the API endpoints your product and your customers depend on, including at least one authenticated path. Fourth, heartbeats on scheduled jobs — backups, billing runs, exports — whose failure is otherwise invisible until you need the result.
Then publish a status page and attach those monitors to it. It costs almost nothing once the monitors exist, and it answers "is it just me?" without anyone emailing you. Each of these steps is small on its own; the reason to sequence them is so that stopping after any one of them still leaves you better off than before.
What you have a month from now
A month after starting, you own three things you cannot buy retroactively: a measured uptime figure for your own service, thresholds that have been tuned against real behaviour instead of guesses, and a short list of the checks that turned out to be noisy — which is itself a map of where your system is fragile. You will also, statistically, have caught something: a certificate nobody was tracking, a cron job that stopped weeks ago, a redirect that broke in a deploy.
None of that requires a large project. It requires that the first monitor exists before the next failure does, which is the entire argument for doing it today rather than after the incident that would have made it obvious.