From Side Project to Production: The Monitorion Journey

Every product starts with a spark of frustration. For Monitorion, that spark was an expired SSL certificate that took down a payment flow for four hours because the monitoring tool we were paying for failed to alert us.

We were running three separate services at the time: one for uptime checks, one for SSL monitoring, and a manual calendar reminder for domain renewals. When the SSL cert expired, the uptime checker still reported "200 OK" — because it did not validate certificates. Four hours of lost revenue and customer trust later, we decided to build something better.

The Problem We Set Out to Solve

Most monitoring tools check your site from one location. If that location has a network hiccup, your phone goes off at 3 AM for a site that was never actually down. After a few false alarms, you start ignoring alerts — which defeats the purpose of monitoring.

We wanted a tool that:

• Checks from multiple regions and only alerts when multiple locations agree something is down
• Monitors more than just "is it up" — SSL expiry, DNS changes, domain registration, security headers, visual regressions, API response content
• Lets you configure exactly when to be alerted — not a one-size-fits-all threshold
• Does not cost $100/month for basic coverage

Building Multi-Region Consensus

The hardest problem was not checking from multiple locations — it was deciding what to do when they disagree. If your site is up in 4 out of 5 regions but unreachable from one, is it "down"?

The naive approach — alert on any failure — is worse than single-location monitoring because you have 5x the chance of a false positive. We implemented consensus voting: a monitor only transitions to "down" when a majority of regions agree. This single decision changed the product from "annoying" to "trustworthy."

From 3 Check Types to 26

We started with HTTP, Ping, and SSL checks. But once the core infrastructure was in place, we kept running into scenarios where basic checks were not enough.

A 200 OK does not mean your site works. Your API might return empty data. Your login page might render a blank screen. Your checkout might silently fail. So we built keyword monitoring, JSON response validation, DOM element counting, and CSS selector checks.

SSL and domain expiry monitoring needed configurable thresholds — not everyone wants the same "30 days before expiry" warning. Some teams want alerts at 60 days. Others only care at 7. We let users set both a warning and a critical threshold per monitor.

Screenshot monitoring was the most interesting to build. We use real pixel-level diffing to detect visual regressions — not just file hash comparison, which triggers on every tiny change from dynamic content. A configurable tolerance threshold catches meaningful changes while ignoring noise.

Fighting False Positives

False positives are the single biggest threat to a monitoring platform's credibility. If your tool cries wolf twice, your team starts ignoring alerts — and then misses the real outage. We invested heavily in reducing them:

• Multi-region consensus — only alert when multiple locations agree
• Automatic retries — transient DNS hiccups and TCP resets often resolve on retry
• Incident deduplication — prevent multiple workers from creating duplicate incidents when checks fire simultaneously from different regions
• Configurable failure thresholds — users choose how many consecutive failures trigger an alert
• Smart timeouts per check type — a DNS lookup should resolve in under 5 seconds, but a Lighthouse audit might legitimately take 30

Lessons Learned the Hard Way

SSRF prevention matters on day one. An early version of our HTTP checker would happily fetch cloud metadata endpoints if a user entered them as a monitor URL. We learned to block private addresses, loopback, link-local, and metadata endpoints from the start. Our private network worker intentionally skips these checks — monitoring internal services is exactly what it is for.

Always be explicit about units. An early bug stored a timeout in seconds instead of milliseconds. This caused checks to set an 8-hour timeout instead of 30 seconds. One-line fix, permanent lesson.

Separate your queries. Complex multi-level database joins silently return null instead of throwing errors. We learned to split complex queries into separate calls and assemble data in application code. More verbose, but predictable.

Screenshot checks are resource-hungry. Each check launches a headless browser, navigates, waits for JavaScript to settle, and captures. Memory management and query optimization (never loading image data in list views) made the difference between a usable feature and one that crashed the server.

Our Philosophy

We ship fast and iterate. Every feature starts as the simplest version that solves the problem, and we refine based on real usage data. We do not build features nobody has asked for, and we do not optimize code that is not a bottleneck.

We also believe in owning our infrastructure. We run our own servers and deploy with a zero-downtime script. When something goes wrong at 2 AM, we fix it directly — no waiting for a support ticket with a platform provider.

The result: a monitoring platform running across 5 global regions for under $30/month in infrastructure costs. No venture capital, no bloated team, no features we do not use ourselves.

What Is Next

We are expanding to more regions, building smarter alerting with anomaly detection based on historical baselines, and working on a public REST API so customers can manage monitors programmatically. The foundation is solid. Now we scale.

Ready to get started? Sign up free — 15 monitors, 7 check types, no credit card required.