Website Monitoring

Website monitoring makes sure your site is always reachable and fast for real users. In the real world, downtime is inevitable: misconfiguration, broken deploys, upstream provider issues, DNS/SSL/load balancer issues… Website monitoring paired with on-call alerting makes sure your team knows about the issue before you hear about it from your users!

---

---

Website Monitoring: HeyOnCall vs. Alternatives

Differentiator	HeyOnCall	Alternatives
Monitoring	Configurable HTTPS probes with assertions that go beyond the URL: response headers, HTTP status codes, redirects, etc.	URL-only 200 OK checks.
Alerting	iOS/Android “Critical Alerts” bypass Do Not Disturb and volume/mute settings. Repeat until acknowledged. Will wake you up!	No mobile app. No critical alerts. Emails or Slack alerts are easy to miss for hours.
On‑call	Integrated on-call rotation schedules and escalations.	Separate products for monitoring and on-call: requires integration glue between them, so there are more moving parts to fail during an outage.
Silencing	Quick silence with selectable timeout at the trigger, service, or organization-wide level. Ensures you don’t keep getting alerts while you’re fixing the issue, and ensures you don’t inadvertently stay silenced forever.	Mute one monitor at a time. Forget to unmute after the incident is over, so you miss the next incident.
False positives (noisy alerts)	Customer-level: False positives are reduced to your preferences via customizable consecutive-failure thresholds / timeouts. Platform-level: False positives are reduced through continuous control group self-checks, extensively tested codebase, and code paths designed to differentiate our network incidents from yours.	¯\_(ツ)_/¯
False negatives (missed alerts / blind spots)	Customer-level: Missed alerts are reduced via: alerts repeat until acknowledged; configurable multiple delivery channels per user; configurable multi-level escalations. Blind spots are reduced via configurable assertion rules on HTTP response headers, etc. Platform-level: False negatives are reduced via extensive CI test suite, continuous production self‑checks, and external monitoring.	Customer-specific glue (webhook integration) between separate monitoring product and on-call product fails silently (webhooks/auth headers/network issues), resulting in missed alerts right when you need them.
Pricing	Simple, flat $/month pricing. Free tier forever.	Annoying $/user/month or $/monitor/month.

---

Website Monitoring FAQs

Why do websites need monitoring?

Monitoring makes sure your site is up, and makes sure you’re the first to know when it’s not.

Anyone who has operated a production website for long enough will tell you that unexpected outages happen: DNS gets misconfigured, SSL certificates expire, somebody updated a dependency, broken deploy… we’re all only human.

If it’s at all important that your website stays up, monitoring and alerting are your first line of defense against eventually-inevitable downtime.

What can go wrong that monitoring catches?

The big categories are misconfigurations, broken deploys, and infrastructure outages. More specific examples:

• DNS failures or wrong records (can’t resolve your domain)
• TCP connection timeouts and resets (network path issues)
• TLS/SSL errors and expirations (broken or expiring certificates)
• HTTP 5xx/4xx, redirect loops, or unexpected status codes (bugs or misconfigurations)
• Server overload (too many requests, too much traffic at once)
• Unresponsive servers (process hangs, memory leaks, restart loops)
• Changed headers or redirects (send users to the wrong place)
• Disk full (can’t write to database, can’t write logs, can’t serve files)
• Load balancer, PaaS provider, or CDN incidents/outages

Who needs website monitoring?

Imagine your site is down for a few hours. Would this affect your revenue or reputation? If so, you probably need monitoring.

That includes just about any team with a user‑facing website or API: startups launching MVPs, SaaS products, e‑commerce stores, agencies, and enterprise product/infra teams.

Who doesn’t need website monitoring?

If you’re pre-launch, you probably don’t need monitoring yet.

If you’re just hosting some cat photos for yourself, you probably don’t need monitoring. (But if you’re hosting cat photos for your users, you probably do.)

I’m hosted by a big cloud provider / PaaS / etc. Don’t they do the monitoring?

Great question. The cloud providers / PaaS we’ve seen tend to have their own monitoring which is internal to their network. They will send health check requests to your app instance, but will bypass many layers of public routing (DNS, SSL termination, load balancers, CDN, etc.).

This internal monitoring may automatically restart your app if it’s unresponsive within their own network. (Key word is “may”. We’ve seen instances where an app was unresponsive or stuck in a reboot loop for hours, but the PaaS didn’t successfully restart it.) But internal-only monitoring won’t confirm if your site is actually reachable at https://<yourdomain>/ from outside their network, like a real user would.

Relying on your cloud provider or PaaS’s built-in monitoring leaves you vulnerable to many layers of the stack: DNS, SSL certificates, issues with their load balancers / CDN / etc.

An external website monitoring service like HeyOnCall sends requests from outside their network, just like a real user would, so you’re monitoring the thing you actually care about.

I have a static site. Do I still need monitoring?

In general, you’ve dramatically limited your surface area by using a static site. Nonetheless, there are still layers of things that can and do break from time to time: DNS, SSL certificates, issues with their load balancers / CDN / etc.

The biggest one is simply misconfiguration: a static site deployment still requires a bunch of configuration knobs on the static site host’s end for your site to be reachable.

Static cat photos? Probably not. Static SaaS marketing site? Probably.

How does HeyOnCall monitor my site?

We send your server a fresh HTTPS request every minute. We record DNS results, TCP connection timeouts, SSL certificate issues, HTTP headers, status codes, uptime and latency with historical graphs. We show you the full request and response headers so you can quickly pinpoint whether it’s a DNS issue, network problem, SSL certificate issue, load balancer issue, or your app.

For advanced users: you can assert specific response status codes and headers, redirects, etc. to make sure your site is behaving as expected.

When do I get alerted?

You choose how long your site needs to be down before we alert.

You probably don’t want to get woken up by a loud alert at 3am if your website is down for 2 minutes and then successfully restarts itself. (It’ll already be resolved by the time you open your laptop.)

On the other hand, if your site is down for a longer period (10 minutes? 30 minutes?), you probably want to get woken up and start debugging.

There are real tradeoffs in setting your timeout threshold, but we typically recommend something in the 5 to 20 minute range: long enough that the issue is unlikely to fix itself.

Who gets alerted?

Alerts route to the on‑call person in your on-call rotation schedule.

This works for solo founders too: until you add teammates, the default on-call schedule is just you, 24/7!

How do I get alerted?

Alerts are sent via the free HeyOnCall mobile apps for iOS and Android.

We have special permissions to deliver “Critical Alerts” on both iOS and Android. Critical alerts bypass the phone’s Do Not Disturb and silent/vibrate modes. They are LOUD and impossible to ignore.

The alerts will keep getting sent repeatedly (at a configurable interval) until you acknowledge the incident.

That sounds incredibly annoying! How do I turn it off?

Acknowledging the incident stops the alerts.

You can also configure non-critical alerts, which will be delivered as normal push notifications. These respect your phone’s normal Do Not Disturb and silent/vibrate modes.

We also have a vibrate-only mode, which will still buzz in your pocket, but won’t make any sound.

During an incident, you can also silence all alerts at multiple levels up to organization-wide, so you don’t keep getting paged while you’re in the middle of trying to debug things.

What if I don’t notice the alert?

We have escalation rules built in. You can configure HeyOnCall to, for example, page the next person after 15 minutes, then page the team’s manager after 30 minutes, then page the CTO after 60 minutes. Any one of those people acknowledging the incident will stop the escalation.

Can I get alerts in Slack?

Yes. Connect Slack and our bot will post messages into your desired Slack channel for team visibility and collaboration. You can use this Slack channel for team awareness, while you rely on the iOS/Android critical mobile alerts for wake-you‑up-at-3am paging.

What makes HeyOnCall better than alternatives?

Alternative solutions often require you to stitch together separate monitoring and on-call alerting tools using brittle webhooks between them. For example: would you really trust your self-hosted monitoring server to be able to send a POST request to your third-party alerting service exactly when you’re in the middle of a flaky network outage? :facepalm: Not exactly a recipe for reliability.

HeyOnCall integrates website monitoring, heartbeat monitoring, on‑call schedules, and alert delivery in one product, which removes fragile links and makes the overall system more reliable.

Critical alerts. On-call schedules. Escalations. Monitoring for websites, APIs, cron jobs, and SSL certificates. All built-in and battle-tested. Designed for developers, by developers. Simple, flat pricing. Free tier forever.

How fast can I get started?

Sign up (free tier forever), add a URL, and start receiving checks in about a minute.