A Day of Setup, and the Alert Still Came Late

My site went down once and I did not find out until the next day. That is what made me set up monitoring: Sentry for errors and an uptime monitor for the site itself. Setting both up took me 1 full day. It did catch a build problem after a deploy, which was worth having. But the alerts themselves kept reaching me after the thing had already passed, which is not what I had been hoping to buy with that day.

What I set up, and what each part was worth

1. An uptime monitor on the site. This was the quick part and the part that solved the original problem. It answers one question, is the site responding, and that was the question I had failed to answer for a whole day.
2. Sentry for application errors. This took much longer: adding it to the project, getting the build to ship source maps so the stack traces meant anything, then working out which errors were mine. It earned its place once, by catching something that broke after a deploy, which is exactly where I had been blind before.
3. Alerting on both. This is the step I did last and thought least about, and it is the one that decided whether the other two were any use.

If you only do one of those three, do the first. It took a fraction of the day and it covers the failure that actually happened to me.

Where the delay really was

I assumed a late alert meant a slow tool. The numbers say otherwise.

UptimeRobot's pricing page, read on 2 October 2026, lists the free plan with 50 monitors and a 5 minute monitoring interval. Paid plans check faster, 60 seconds on Solo and 30 seconds on Team. So on a free plan the tool can know within about 5 minutes that the site is down.

Those five minutes were never the delay. What happened after them was: the alert went to email, and I read email when I next happened to look at it. Detection took minutes and my reaction took hours, so the chain ran at my speed. Upgrading to 30 second checks would have improved the fast part of a chain whose slow part is a person.

The same page notes that free includes email, SMS, voice call and Email2SMS as channels, but SMS and voice credits are not included and have to be added. That pricing detail is the real decision in this whole exercise. The channel that reaches you in minutes is usually the one that costs money, and the channel that is free is the one you check when you feel like it.

Why Sentry took most of the day

An uptime monitor watches your site from outside and needs nothing from your code. Error tracking has to live inside the application, and that is where the hours went.

Installing it takes minutes. Making it useful took me the rest of the day. Without source maps uploaded from the build, the stack traces point at minified code and tell you almost nothing, so that has to be wired into the deploy. Then there is the noise: errors from browser extensions, from bots, from people on old browsers. Until you have filtered those, every alert is a maybe, and a maybe does not get you out of your chair.

It did pay for itself on one deploy. Something broke after a release and Sentry told me what, which is the failure mode I most want to catch, and the one I had previously found out about from a page that looked wrong. I ran into the other half of that problem in deploying to Hostinger, where a half finished upload left the site serving two builds at once.

What I would do in this order now

Put an uptime monitor on the site today. It is the cheapest insurance against the thing that actually happened to me, and it takes minutes.

Then pick the alert channel before you pick any more tools. Decide honestly where a message reaches you inside five minutes, and if the honest answer is nowhere free, that is the thing to spend money on rather than a shorter check interval.

Add error tracking after that, and budget most of a day for it rather than an hour. Count the source maps and the noise filtering as part of the job, because an unfiltered error tracker becomes a second inbox you learn to ignore.