What is Sentinel Watch?

Sentinel Watch is a free website uptime monitoring tool. It checks HTTP(S) URLs on a 5-minute schedule, emails you when a check fails or recovers, warns before SSL certificates expire, and can publish a public status page with 90-day uptime bars. There is no credit card and no paid plan on this product today.

Is Sentinel Watch really free forever?

Yes. The hosted product is free to use within honest limits: 50 monitors per account by default, 5-minute check intervals, email alerts, and 30 days of check history. We do not show a pricing upsell, trial countdown, or “Pro” paywall. Limits can be raised by an admin for legitimate use. If something is unavailable, you will see a clear message — not a fake-healthy dashboard.

How often do you check my website?

Every 5 minutes. That is the same interval UptimeRobot advertises on its free plan. We do not currently offer 30-second or 60-second intervals. If you need sub-minute detection, a paid multi-location tool or a self-hosted checker is a better fit.

What kinds of monitors are supported?

HTTP and HTTPS URLs. Optional keyword matching (alert if expected text is missing), expected status codes, and SSL expiry warnings. We do not yet offer ping, TCP port, cron heartbeats, Playwright journeys, SMS, Slack, or voice alerts. Pause a monitor during maintenance so those checks do not fire.

How do public status pages work?

When you mark a monitor as public, it appears on a shareable /status/[slug] URL. Visitors see an overall operational banner, per-service 90-day bars, and a recent incident timeline. No account is required to view it. Custom domains and email subscribers are not included yet.

Email OTP only. We send a one-time code to your inbox. There are no passwords to store or reset. Use the same email every time so your monitors stay attached to that account.

Website Uptime Monitoring: How It Works

Website uptime monitoring is a scheduled, outside-in check that requests a public URL (usually over HTTPS), records whether the response succeeded, how many milliseconds it took, and optionally whether expected text or a TLS certificate still looks valid. A typical hobby or indie setup runs that check every five minutes from one network, emails the owner on failure and recovery, and may publish a status page so customers are not left guessing. Faster intervals (30–60 seconds) and extra locations reduce detection delay and false positives; they are what paid tools sell. Uptime is not the same as “the app works”: a 200 OK from a cached error page still looks up. Keyword checks, SSL expiry, and pausing monitors during deploys are the features that keep the signal honest. This article explains those pieces so you can pick a free hosted checker, a paid suite, or self-hosted software without marketing fog.

What website uptime monitoring is

From the outside, an uptime monitor is a cron job with a memory. It stores a list of targets, hits them on a schedule, and writes a time series of UP or DOWN plus latency. When the result flips, it notifies someone. That is the whole product category, from Pingdom and Freshping through HetrixTools, Cronitor, Checkly, Oh Dear, and UptimeRobot.

Inside the network, APM and logs answer different questions (why a query is slow, which pod restarted). Uptime monitoring answers the customer question: can a stranger on the internet reach this URL right now? If you only watch CPU, you will miss a registrar DNS failure. If you only watch uptime, you will miss a broken checkout that still returns 200. Serious teams use both. Indies often start with uptime because it is cheap and the failure mode is obvious.

Check intervals and what “5 minutes” means

Interval is how long you are willing to be down before anyone is told. At five minutes you can be offline for up to one interval plus processing time before the first failure email. UptimeRobot’s long-standing Free plan uses five minutes; paid plans advertise 60, 30, or 15 seconds. Better Stack and Oh Dear emphasize one-minute or faster multi-location checks. Checkly is built for synthetic Playwright journeys on a schedule you define as code.

Multi-location checks exist to fight “it is down for the probe, not for users.” A single region can false-positive on a peering blip. Sentinel Watch currently checks from one network location. That is an honest limitation: cheaper, simpler, more false positives than a 20-region mesh.

Heartbeats (Cronitor, Kuma, UptimeRobot) invert the model: your job pings the monitor, and silence is the incident. That is the right tool for “did the backup run,” not for “is the homepage up.”

What to check besides HTTP 200

Keyword / content checks

Reverse proxies, parked domains, and CDN error pages love returning 200. A keyword check fails if a string is missing from the body (or, on some vendors, if a string unexpectedly appears). It is the cheapest way to catch “the site is up but it is the wrong site.”

TLS / SSL expiry

Certificates still expire on Fridays. A dedicated SSL watch emails you 7–30 days ahead. Some vendors gate SSL monitors behind paid plans even when HTTP is free; if that is a deal-breaker, confirm the comparison table, not the homepage hero.

Latency thresholds

“Slow” is not “down.” Paid tools let you alert when TTFB exceeds N milliseconds. Useful for APIs; noisy for a blog on a cold start. Record latency anyway — 90-day bars that only show green hide a 4-second homepage.

Ping, port, DNS, domain expiry

ICMP ping and TCP ports catch “the box is dead” vs “nginx is misconfigured.” DNS monitors catch hijacks and forgotten records. Domain expiry is a calendar problem that uptime HTTP will not see until the name stops resolving. Sentinel Watch does not implement these types yet; Uptime Kuma and the large SaaS tools do.

Alerting without noise

The failure modes of alerting are missing the outage and waking up for a blip. A workable pattern is: email on first failure, a second email once downtime is confirmed across another check, then a recovery email. Pause or maintenance windows during deploys so your own rollout is not an incident. Slack, SMS, and voice exist because email is slow on a phone; they also cost money and get ignored in noisy channels. Do not buy SMS until email has actually missed an incident you cared about.

Public status pages

Statuspage (Atlassian), Better Stack, Instatus, and UptimeRobot all sell the same visitor experience: a banner (“All systems operational” vs partial outage), component list, 90-day bars, incident timeline, optional subscribe. Bundling the page with the monitor avoids a second vendor and a stale green page. Custom domains (status.yourproduct.com) and subscriber lists are the usual paid differentiators. For a side project, a path like /status/your-slug is enough if you link it from the footer.

Read how Sentinel Watch status pages work.

How to choose a free vs paid tool

Use this decision order:

If you already run Docker and want full control, start with Uptime Kuma.
If you need 30–60s, many regions, SMS, or on-call, look at UptimeRobot paid, Better Stack, Checkly, Pingdom, or Oh Dear — see vs UptimeRobot and vs Better Stack.
If you need monitoring-as-code and Playwright, Checkly is the category, not a 5-minute HTTP ping.
If you have a few HTTPS URLs, email is fine, and you want a hosted status URL without a bill, a free hosted checker is enough.

Ignore homepage user counts and star widgets unless you can click through to a real review. This site does not display fabricated social proof.

What Sentinel Watch implements

Sentinel Watch is the hosted checker behind this site. It signs you in with email OTP, stores monitors, runs HTTP(S) checks every five minutes, supports keywords and SSL warning windows, emails downtime and recovery, and publishes optional public pages. Default cap is 50 monitors. History is about 30 days. Pause/resume/delete are in the dashboard. There is no SMS or Slack backend. If hosting limits are hit, the product shows an explicit message instead of a silent empty dashboard. Details live on features and pricing.

Website uptime monitoring: how it works and what to measure