Uptime monitoring: catch downtime, broken content, and SSL expiry before customers do

HTTP 200 isn't the same as "the site works"

The classic uptime monitoring setup checks if your site returns a 200 status code every 5 minutes. If it does, all green. The problem: a 200 status code means the web server responded — not that the page rendered, not that JavaScript loaded, not that the checkout button is on the page, not that the cookie banner didn't lock everyone out of using anything.

We've seen sites where the homepage returned 200, the support team had no idea anything was wrong, and conversions had dropped 90% for six hours because a deploy broke a cookie banner script that blocked all subsequent UI. The uptime monitor was happy. The customers were not.

Modern uptime monitoring needs three signals in parallel:

• Status code — did the request succeed at the HTTP layer?
• Content presence — does the page actually contain the text or element that should be there (a CTA button, a product title, the price)?
• SSL/TLS health — is the cert valid, not expiring in 14 days, configured correctly?

This guide is how to set that up — for production sites, APIs, marketing pages, and anything else that needs to stay online with the right content visible.

What real uptime monitoring includes

A complete uptime check on a single URL runs four checks each poll cycle:

1. DNS resolution — does the hostname resolve to an IP? (Common silent failure: expired domain, broken DNS provider.)
2. HTTP status — does the server respond, and with what status code? You typically want 200; anything 4xx or 5xx is down.
3. Content check — does the response body contain (or NOT contain) specific text? "Welcome back" should be present; "Internal Server Error" should be absent.
4. SSL certificate — is the cert valid? When does it expire? Is the chain complete? Modern monitoring should alert at 14 days before expiry, not on the day-of.

Each of these can be a separate alert. A 500 response is one kind of incident; a missing "Add to cart" button on a working server is another. An SSL cert expiring in 7 days is a quiet but urgent third.

Seven things people uptime-monitor

1. Production website homepage

The baseline. Watch your root domain every 2 minutes for status code + content presence. Pick a single phrase from your hero (the company name, the H1 text) and assert it must be present. This catches both server-down events and silent template breakage.

2. Critical pages — checkout, signup, pricing

Pages where breakage costs money. Watch each individually. For checkout pages, the "content presence" check is the difference between "page loads" and "page works" — make sure the actual checkout form or payment button text is present.

3. API endpoints

Public REST endpoints can be watched the same way. Watch /api/health for status 200 + expected JSON response. Watch /api/products for non-empty array. ViewCel will execute the HTTP request and let you assert on the response body.

4. SSL certificate expiry

The boring but recurring incident. Cert expires Sunday at 3am; nobody notices until customers complain Monday morning. ViewCel tracks SSL expiry on every check and alerts at 14, 7, 3, and 1 day. Includes the chain validity and the issuer change detection (if a cert is suddenly issued by a different CA than expected, you want to know).

5. Cookie banner / consent gate breakage

A specifically-EU problem. Your cookie consent UI is third-party JavaScript (Cookiebot, CookieYes, OneTrust). When it breaks, users see a banner that won't dismiss and can't interact with the page. The HTTP response is 200; the page is "down" from a UX standpoint. Setting a content check that requires the actual page content (not just the banner overlay) catches this.

6. Third-party dependency drift

Your homepage embeds a Stripe checkout button, a Calendly widget, a YouTube video. If the third party changes their embed format or rate-limits you, your page silently degrades. Watch for the embed element being present and rendering (not just the page returning 200).

7. Multi-region availability

A US-only outage of your CDN POP is invisible from EU monitoring. A truly redundant uptime setup polls from multiple regions. ViewCel today polls from EU primary; multi-region is on the roadmap (get in touch if it's a hard requirement and we'll prioritize).

How to set up uptime monitoring in ViewCel (5 steps)

1. Pick your URLs. Start with: root domain, signup page, checkout/pricing, one critical API endpoint. Four targets is plenty for a typical SaaS. Don't watch every page — uptime monitoring is for the URLs where breakage costs money or trust.
2. Create monitoring targets with type "uptime" (or "both" if you also want a screenshot of the page at the moment of incident). The default check interval on Pro plans is 2 minutes; drop to 5 or 15 minutes for less critical URLs.
3. Add a content assertion. Per target, set a "must contain" text (a phrase from your hero, a button label, a JSON field name). This converts a basic HTTP check into a real "is the page working?" check.
4. Configure SSL monitoring. Enabled by default on HTTPS targets. Set the warning threshold to 14 days (default) and the recipient(s) for SSL alerts — usually different humans than the on-call rota for downtime.
5. Set up the alert routing. Email for the SSL warnings (non-urgent, planned work). Webhook → PagerDuty / Opsgenie / Slack #alerts for downtime (urgent, wake people). Multiple recipients on Business plans.

Quick-reference recipes

Why ViewCel for uptime monitoring

• Content checks built-in, not bolted on. Every check can assert text presence/absence. No extra plan or add-on.
• SSL expiry tracked per target by default. 14/7/3/1-day warning ladder; one less thing to forget.
• 2-minute polling on paid plans. Tight enough that customers don't notice the incident before you do.
• Real browser rendering. JavaScript-rendered pages (SPAs, Next.js, Nuxt) work the same as static ones. Cookie banner break detection works because we run the actual page.
• Incident dedupe. A 3-failure threshold before the alert fires (configurable per target) — no false 1-blip wake-ups at 3am.
• Webhook + multi-recipient email. Pipe to PagerDuty/Opsgenie for on-call, email for non-urgent.
• One product for monitoring + change detection + SEO scoring. If you're already using ViewCel for any of those, uptime is in the same dashboard.

FAQ

How is this different from UptimeRobot or Pingdom?

UptimeRobot and Pingdom are pure uptime tools with multi-region polling, public status pages, and dedicated incident response features. ViewCel is a general web-monitoring tool with uptime as one of three first-class concerns (alongside change detection and SEO scoring). Trade-off: ViewCel has deeper content/JS rendering and SSL detail by default; UptimeRobot/Pingdom have more polished incident management and status pages.

Does ViewCel publish a public status page?

Not today. Status pages are on the roadmap — for now, ViewCel sends alerts to your channel of choice (email/Slack/webhook) but doesn't host a customer-facing status page like StatusPage.io or BetterUptime. Pair with a dedicated status-page tool if that matters.

How quickly will I get notified after an incident?

Polling interval + dedupe threshold + notification dispatch. With 2-minute polling and a 3-failure threshold (default), worst case is ~6 minutes from incident start to alert. You can lower the threshold to 1 failure if you'd rather catch single-blip incidents and accept some false positives.

How precise is the SSL expiry tracking?

ViewCel reads the certificate directly from the TLS handshake on each check — same data your browser sees. Expiry, issuer, chain validity, valid-from date, alternate names. Alerts trigger on the standard 14/7/3/1 day ladder; configurable per target.

Can I monitor IP addresses or just URLs?

ViewCel monitors URLs (HTTP/HTTPS). For TCP-level "is port 443 open on IP X" probes, use a dedicated network monitoring tool like Better Stack or Nagios. For "is the website at https://X loading and serving the right content", ViewCel.

Will the alerts wake me up at 3am for false positives?

By default no — incident dedupe (3 consecutive failures before alert) filters single-blip false positives. The downside: ~6 minutes of incident before the alert fires. Tighten the threshold per target if you have a more sensitive page; loosen it for flaky third-party-dependent pages.