1. Explanation
  2. How uptime monitoring works

Explanation

How OnlineOrNot monitors uptime

OnlineOrNot continuously monitors your URLs from multiple locations worldwide. Here's how it works.

The monitoring loop

For each uptime check, OnlineOrNot:

  1. Makes an HTTP request from one of our monitoring regions
  2. Evaluates the response against your configured criteria
  3. Repeats at your configured interval (1-5 minutes)

What counts as "up"?

By default, a check is UP if:

  • The request completes within the timeout
  • The response status code is 200

You can customize this with:

  • Text search - Verify specific content appears on the page
  • Assertions - Check response headers, JSON values, or HTML elements
  • SSL verification - Ensure the certificate is valid
  • Status codes - Accept other codes as successful

What counts as "down"?

A check fails when:

  • Request times out
  • Connection fails
  • Status code indicates error (4xx, 5xx)
  • Any configured assertion fails
  • SSL certificate is invalid (if verification enabled)
  • Required text is missing

Multi-region verification

A single failed check doesn't immediately trigger an alert. OnlineOrNot:

  1. Detects initial failure
  2. Re-checks from the same region
  3. Checks from other regions
  4. Checks from Cloudflare's global network
  5. Waits for confirmation period

Only after verification from multiple locations does OnlineOrNot declare an incident.

Why multi-region matters

Your server might be fine, but:

  • A regional ISP could be having issues
  • DNS propagation might affect some regions
  • A CDN edge location could be down

Multi-region verification distinguishes between "my site is down" and "some users can't reach my site."

Check frequency vs. detection time

Higher frequency means faster detection:

Interval Worst-case detection
1 minute ~2 minutes
3 minutes ~6 minutes
5 minutes ~10 minutes

The "worst-case" includes time for verification and confirmation period.

Browser checks vs. uptime checks

Uptime checks make simple HTTP requests. They're fast and efficient but can't:

  • Execute JavaScript
  • Render pages
  • Handle client-side routing

Browser checks use a real browser. They can:

  • Test JavaScript-heavy SPAs
  • Verify content loaded by client-side code
  • Simulate user interactions

Use browser checks when your content is rendered by JavaScript (React, Vue, etc.).