Thoughts on Monitoring

Why Your Monitoring Tool Shouldn't Need Its Own Server

---

It's 3:17am. Your phone buzzes with an alert: "Production API is down." You scramble to your laptop, open your monitoring dashboard, and are greeted with… a loading spinner. Then a 502 error. Your monitoring tool — the one thing that's supposed to tell you what's broken — is itself broken.

This isn't a hypothetical. It happened to us. And it's the reason Uptimes exists.

The Infrastructure Paradox

Traditional uptime monitoring services operate on a simple model: you give them a URL, and their servers ping it at regular intervals. When something goes wrong, they notify you. The problem? Those pings originate from their infrastructure — servers hosted in data centres, running on cloud providers, with their own uptime dependencies.

This creates what we call the Infrastructure Paradox: to monitor your infrastructure, you depend on someone else's infrastructure. It's turtles all the way down.

"The best monitoring tool is the one that has zero infrastructure to fail."

Think about it. Services like UptimeRobot, Pingdom, and Better Uptime are excellent products — but they all share a fundamental architectural assumption: that reliable monitoring requires a persistent server. We challenged that assumption.

What If Monitoring Lived in the Browser?

Modern browsers are remarkably powerful. The fetch() API can make HTTP requests. The performance.now() API provides sub-millisecond timing. localStorage and IndexedDB offer persistent storage. Service workers can run background tasks. The browser is, in many ways, a fully-fledged runtime environment.

So we asked: what if we built an entire monitoring system using only browser APIs?

That's exactly what Uptimes does. It's a Chrome extension that pings your endpoints every 60 seconds, records response times, calculates uptime percentages, and renders real-time heartbeat visualisations — all without ever sending a single request to our servers. Because we don't have servers.

How It Works Under the Hood

The architecture is deceptively simple:

async function pingEndpoint(url) {
  const t0 = performance.now();
  try {
    await fetch(url, { mode: 'no-cors', cache: 'no-store' });
    const ms = Math.round(performance.now() - t0);
    return { status: 'up', ms, timestamp: Date.now() };
  } catch (err) {
    return { status: 'down', ms: 0, timestamp: Date.now() };
  }
}

Every 60 seconds, this function runs for each URL you've added. The results are stored in chrome.storage.local, which persists across browser restarts. The extension popup reads that storage and renders the UI — heartbeat bars, response time charts, and statistics.

Why no-cors?

We use mode: 'no-cors' because we don't need to read the response body. We only care about two things: did the request complete? and how long did it take? This means Uptimes can ping any publicly accessible URL — even ones without proper CORS headers — because we're not trying to read the response.

The Privacy Advantage

Because everything runs locally, your monitoring data never leaves your device. We don't know which URLs you're monitoring. We don't know your response times. We don't even know you installed the extension. This isn't a privacy policy — it's an architectural guarantee. There is physically no server for your data to be sent to.

Trade-offs We Accept

We're not pretending Uptimes replaces enterprise-grade monitoring solutions. There are real trade-offs:

• Browser must be open: Pings only run while your browser is active. Close the browser, monitoring pauses.
• No multi-location checks: Pings originate from your machine, not from global edge nodes.
• No alerting infrastructure: We can show a red badge, but we can't send you a Slack message or PagerDuty alert (yet).
• Local storage limits: History is bounded by browser storage quotas.

For many developers — especially those working on side projects, staging environments, personal APIs, or localhost services — these trade-offs are more than acceptable. You're trading global coverage for zero setup, zero cost, and zero data exposure.

Who Is Uptimes For?

Based on feedback from our 10,000+ users, here's who finds Uptimes most valuable:

• Indie developers monitoring their SaaS apps and API endpoints without paying for Pingdom.
• Freelancers keeping an eye on client websites during handoff periods.
• DevOps engineers doing quick, ad-hoc checks on staging or internal services.
• Students and educators who need a visual way to understand HTTP, latency, and uptime concepts.
• Security-conscious developers who refuse to give a third-party access to their URL list.

What's Next

We're actively working on several features that will push browser-based monitoring further:

• Service Worker pings: Background checks that persist even when the popup is closed.
• Browser notifications: Native alerts when an endpoint goes down, no server required.
• Export & share: Generate shareable status pages from your local data.
• Multi-browser sync: Optional encrypted sync across your own devices.

The future of developer tools isn't more servers. It's smarter clients. Uptimes is our proof that powerful monitoring can live entirely in the device you already have open — your browser.

---

Written by the Uptimes team · Try it yourself →