The Monitoring Stack: Uptime, Errors, and Alerts That Actually Tell You Something

Your site went down three days ago. You found out because a reader emailed you. Google found out before you did — and Google holds grudges. Monitoring automation exists to close that gap, and the good news is that the practical version of it costs nothing and takes twenty minutes to set up. The bad news is that most people skip it until after the emergency, when the fix is more expensive and the SEO damage is already done.

This isn't enterprise observability with Grafana dashboards and on-call rotations. This is the solopreneur monitoring stack — the minimum viable setup that tells you when something breaks before your audience notices. It covers uptime, SSL certificates, API health, and the alerting layer that ties it all together. If you run websites that make money, this is the automation that protects the other automations.

What The Docs Say

The documentation for monitoring tools paints a clean picture. UptimeRobot checks your site every five minutes from multiple global locations and alerts you via email, SMS, Slack, or webhook when it detects downtime. Better Stack does the same thing with a prettier interface and incident management baked in. Self-hosted monitoring via n8n uses HTTP request nodes on a schedule to ping your endpoints and trigger alerts on non-200 status codes.

SSL certificate monitoring is supposed to be handled automatically by Let's Encrypt and your hosting provider — certificates renew 30 days before expiry, no intervention needed. The docs say you'll never think about it. DNS monitoring checks that your records haven't changed unexpectedly, which matters if you're using Cloudflare or a CDN that could misconfigure on an update. And Ghost-specific monitoring uses the Admin API's health endpoint to verify that your CMS is responsive even when the frontend appears fine.

The pitch across all these tools is the same: set it up once, forget it, get notified when something goes wrong. The tools are mature, the APIs are stable, and the free tiers are generous enough for most solopreneur setups.

What Actually Happens

The tools work. That's the straightforward part — UptimeRobot's free tier genuinely monitors 50 endpoints at five-minute intervals and sends alerts reliably. I've been running it across 15+ sites for over a year, and it catches downtime within five minutes consistently. The false positive rate is low. The setup takes about ten minutes per site. On the monitoring side, the docs are telling the truth.

Where things get interesting is the alerting layer. The first week you set up monitoring, you'll get alerts and respond to every one. By week three, you're getting three Slack notifications a day — a brief blip that resolved itself, a timeout that wasn't actually downtime, a check that failed because UptimeRobot's own node had a hiccup. This is alert fatigue, and it's the real failure mode of monitoring automation. Not that the alerts don't fire — that you stop reading them.

SSL monitoring sounds redundant if you're using Let's Encrypt with auto-renewal, but auto-renewal fails more often than the docs suggest. A misconfigured Nginx reverse proxy, a DNS change that breaks the ACME challenge, a hosting provider migration that doesn't carry over the renewal cron job — I've seen all three cause certificate expiry on sites that were "automatically" managed. A separate SSL monitor that alerts 30 days before expiry is cheap insurance against the "your site shows a security warning and you don't know" scenario. [VERIFY] UptimeRobot includes SSL monitoring on its free tier; Better Stack requires the paid plan for certificate checks.

Ghost-specific monitoring is worth calling out. Ghost can crash in a way that doesn't immediately take down the frontend — if you're running Ghost behind a CDN like Cloudflare, the cached version keeps serving while the actual Ghost instance is dead. Visitors see a working site. You see a working site. But new posts won't publish, the admin panel is unreachable, and email sends fail silently. Monitoring the Ghost Admin API health endpoint catches this. An n8n workflow that hits yourdomain.com/ghost/api/admin/site/ every fifteen minutes and alerts on non-200 responses is the simplest version of this, and it's caught Ghost crashes for me that would have gone unnoticed for days.

The n8n approach to monitoring — building your own checks with HTTP request nodes and conditional alert logic — is more flexible than SaaS tools but introduces a dependency loop. You're using n8n to monitor services, but who's monitoring n8n? If your n8n instance goes down, your monitoring goes down with it. The practical answer is to use UptimeRobot (hosted SaaS, not dependent on your infrastructure) for uptime monitoring and n8n only for custom health checks that UptimeRobot can't do — like Ghost API health or checking that a specific API endpoint returns valid data, not just a 200 status code.

When To Use This

The minimum viable monitoring stack is UptimeRobot plus a Slack channel. Create a free UptimeRobot account, add your sites as HTTP monitors with five-minute intervals, enable SSL monitoring for each, and point the alerts at a dedicated Slack channel or email address. This covers uptime and SSL for up to 50 endpoints and takes about twenty minutes to configure. If you stop reading this article here and just do that, you're ahead of 90% of solopreneurs.

The next tier — and the one I'd recommend if you run Ghost or any CMS with an API — adds n8n health checks. A simple workflow runs every fifteen minutes, hits your Ghost Admin API endpoint, and sends a Slack notification if the response isn't 200. Add another workflow that checks your critical API endpoints — Stripe webhook receiver, email sending service, whatever your operation depends on. This tier takes an hour or two to set up and catches the failures that basic uptime monitoring misses.

Error alerting with thresholds is the tier after that. Instead of alerting on every non-200 response, you configure n8n to alert only when an endpoint has been down for two consecutive checks — ten minutes of confirmed downtime, not a single blip. This eliminates most false positives and means that when your Slack channel lights up, it's actually worth looking at. The n8n workflow uses a simple counter stored in a variable — increment on failure, reset on success, alert when the counter hits your threshold.

The cost structure is straightforward. UptimeRobot's free tier handles 50 monitors, which covers most solopreneur operations. The paid tier starts at $7/month [VERIFY] and adds 1-minute checks, more monitors, and maintenance windows. Better Stack starts around $24/month [VERIFY] and includes incident management with status pages — nice but not necessary at this scale. n8n self-hosted is free if you already have a server. n8n Cloud starts at $20/month. For most people, UptimeRobot free plus self-hosted n8n is the sweet spot.

When To Skip This

If you run a single site with no API dependencies and no revenue attached to it, UptimeRobot free by itself is sufficient. You don't need custom n8n health checks or multi-tier alerting for a personal blog. The monitoring stack described here is for operations where downtime costs money or reputation — multiple sites, active subscriber bases, payment processing, or content that's being indexed by Google where downtime affects search rankings.

Skip the self-hosted monitoring approach entirely if you don't already run n8n or another automation server. Setting up infrastructure to monitor other infrastructure is a rabbit hole. Use the hosted SaaS tools, pay the $7-24/month if you need features beyond the free tier, and spend your time on the work that actually generates revenue. Monitoring is insurance, not a product — and the goal is the minimum effective dose, not comprehensive observability.

Also skip over-engineering the alert routing. You don't need PagerDuty, you don't need on-call schedules, and you don't need alerts going to your phone at 3am unless you're running infrastructure where a three-hour delay in response time actually matters. For most solopreneur operations, a Slack channel checked during business hours is enough. The site can be down for a few hours overnight without catastrophic consequences. Design your alerting for your actual response capacity, not for the enterprise playbook.

This is part of CustomClanker's Automation Recipes series — workflows that actually run.