Free website monitoring with real-time alerts

Why monitor the availability of your URLs

An uptime of 99.9% still leaves room for 43 minutes of downtime a month. The hard part is knowing when those minutes happen. Without automated monitoring, an outage is usually discovered through a customer email, often several hours after it started. In the meantime, the conversion funnel is broken, forms no longer submit, and Googlebot records 5xx responses.

The mechanism is simple: a request sent at a regular interval, a response recorded, an alert as soon as that response steps outside what is expected.

Four reasons to monitor your endpoints:

• Detect before your users do: an application crash or a hosting outage surfaces within minutes, not with the first support ticket.
• Protect your search rankings: prolonged 5xx errors on indexed pages degrade crawling and ranking.
• Cover critical paths: checkout page, REST endpoint, contact form.
• Validate your migrations: the check history shows exactly when the regression appeared.

How to use HTTP monitoring in 3 steps

Step 1: Enter the URL to monitor

Enter the full URL of the endpoint, protocol included:

https://captaindns.com/en/pricing

Start with the URLs where downtime costs you money right away: homepage, checkout, public API.

Step 2: Set the interval and the alert conditions

Three settings cover most cases:

• Interval: 5 minutes by default. A cron expression takes over for specific needs (business hours only, or a maintenance window left out of the schedule).
• Expected HTTP code: any 2xx code by default. Set a single exact code if the endpoint must return precisely that one, for instance 301 for a redirect or 401 for a protected endpoint.
• Email alerts: an on/off switch per monitor. The emails go to your CaptainDNS account address, there is no per-monitor recipient to enter. On paid plans, an HTTPS webhook can route to Slack, Discord or PagerDuty.

Step 3: Run a check and read the metrics

Trigger an immediate check to validate the configuration. The result appears within seconds, with the HTTP code, the total response time and, where relevant, the error code. The dashboard then aggregates uptime over 24 hours, 7 days and 30 days, average and p95 response time, the heatmap and the incident list.

How an HTTP check works

Every check runs through four stages, and each one can fail independently of the others.

1. DNS resolution

The hostname in the URL is resolved. A failed resolution (NXDOMAIN, SERVFAIL, timeout) marks the check dns_error and triggers an alert.

2. TCP connection and TLS handshake

A TCP connection is opened to the resolved IP. Over HTTPS, the TLS handshake validates the certificate chain, checks the expiration date and confirms that the hostname matches. An expired or invalid certificate marks the check tls_invalid.

3. HTTP request and response read

The request is sent (GET by default, or the configured method). CaptainDNS waits for the configured deadline, 10 seconds by default and 30 seconds at most. Beyond that, the check is marked timeout. The HTTP code and the total response time are recorded.

4. Evaluation and alerting

A check is up if the HTTP code is a 2xx, or if it exactly matches the expected code when you have set one. A 5xx, a code outside what is expected, a timeout or a network error marks it down. A confirmed transition from up to down triggers an alert; the return to up sends a recovery email that closes the incident.

Monitor your site from multiple regions

A single-region monitor tells a partial truth. If your only probe lives in Europe and a transatlantic transit provider has a problem, the site appears to be up while your US customers cannot reach it. Conversely, a local network incident near the probe makes a healthy site look globally down.

CaptainDNS runs checks from three zones on Fly.io infrastructure: Europe (eu) for the EU, the United Kingdom and North Africa; United States (us) for North America and part of Latin America; and Asia-Pacific (apac) for Japan, Korea, Southeast Asia and Oceania. How many regions you can enable depends on your plan: a single one (Europe) on entry plans, up to three above that. See plans and pricing.

Three DOWN detection strategies

Running several probes raises a question: how many failing regions should it take before the site counts as DOWN?

• Consensus (default): the monitor flips DOWN when at least half of the regions fail. False positives caused by an isolated network incident are filtered out, while a real outage still surfaces quickly.
• Strict: a single failing region is enough. Suited to critical monitors (payment, real-time API) where even a brief regional flap must surface.
• Unanimous: the monitor only flips DOWN when every region fails. Suited to distributed infrastructure (active-active CDN, edge compute) that tolerates regional flaps.

With a single active region, the three strategies produce the same result: the choice only becomes meaningful from two regions onward.

Analyze your site's security posture

An uptime monitor answers one question: is the site responding? It says nothing about the quality of what it returns. A site can return 200 in 80 ms for months with a certificate close to expiry, an HSTS header dropped by a reverse-proxy deployment, or a CSP switched back to unsafe-inline. Posture monitoring closes that blind spot: it periodically recalculates a security score on the URLs you already monitor, and alerts you when it degrades.

The five components analyzed

• SSL/TLS certificate: validity, chain of trust, expiration date, accepted TLS versions.
• HSTS: header presence, max-age duration, subdomain coverage, preload status.
• Security headers: CSP, X-Frame-Options, Referrer-Policy and the associated defense in depth.
• Page weight: the volume of loaded resources, a signal of performance hygiene.
• Reputation (phishing): the monitored URL checked against threat databases (Google Web Risk, URLhaus, VirusTotal), measured once a day.

You choose which components to track, and at least one must stay selected. Unchecking a component excludes it from the calculation without skewing the score: its weight is redistributed across the remaining components.

A score out of 100 split into two areas

The overall score is a weighted average of Security (80 points), covering the certificate, HSTS, security headers and reputation, and Performance (20 points), covering page weight. Each component falls into a readable band: Excellent, Good, Needs improvement or Critical. Security counts four times as much, because a broken certificate exposes your visitors whereas a heavy page only slows them down.

Frequency, baseline and alerts

On the first scan, CaptainDNS records a baseline without sending an alert. After that, every notable change triggers a component-by-component summary, and a preemptive alert is sent before the certificate expires, at 30, 14, 7, 3 and 1 day. A dedicated tab shows the current score and 180 days of change history.

Posture runs from Europe only: the certificate, HSTS and headers do not vary by observation point. It is available from the Solo plan; the shortest scan frequency and the number of monitors allowed per root domain both depend on the plan (see plans and pricing).

The score and its components can also be published on a public status page: you choose, monitor by monitor, which elements are visible (score out of 100, certificate, HSTS, headers, page weight, reputation). Nothing is published by default.

Email alerts and webhooks

An alert is sent as soon as a check falls outside the expected conditions. The table below lists the conditions that trigger one.

Three guardrails against noise

A flapping site can generate dozens of alerts per hour. Three mechanisms prevent that:

1. Confirmation over consecutive failures: by default, no alert goes out before two failed checks in a row. The threshold is configurable from 1 to 10 failures in the monitor settings.
2. Progressively spaced reminders: one alert at the start of the downtime, then at most one reminder per hour during the first 24 hours of the episode, and one reminder every 24 hours beyond that. A recovery alert closes the incident when the site comes back.
3. Auto-disable: a day counts as lost when no check succeeded that day. On the 5th consecutive lost day, a warning email is sent; on the 7th, the monitor is disabled.

The alert email contains the URL involved, the HTTP code or error type, the latency of the last successful check, the UTC and local timestamps, and a link to the dashboard. No tracking pixel.

HTTP webhooks

Email is not the right channel for routing to Slack, Discord, PagerDuty or an internal incident management system. On paid plans, one or more HTTPS endpoints receive events as JSON POST requests, signed with a shared secret so the receiver can validate the origin. Each webhook subscribes to the categories it cares about, three in total: Monitoring, Deployment and DNS. Availability alerts fall under Monitoring and can go to a Slack ops channel, while a second webhook receives only Deployment events. When delivery fails, CaptainDNS retries with exponential backoff and logs every attempt.

Uptime metrics, p95 latency and 30-day heatmap

The dashboard aggregates raw checks into six metrics.

The p95 latency is the more useful indicator of perceived performance. The average hides spikes; p95 tells you what your users experience in the worst 5% of cases.

30-day heatmap

The heatmap visualizes the last 30 days as a colored grid. Each cell covers one full UTC day, never a finer window, and takes its color from that day's uptime: green above 99.5%, orange between 90% and 99.5%, red below 90%, gray when there is no data.

History and retention

Every individual check stays available for 30 days on the free plan: timestamp, HTTP code, total response time, error code where relevant. After that, individual checks are deleted automatically. Detailed retention increases on higher plans, up to the 90-day ceiling applied across every plan. Daily aggregates (uptime, average latency) are never purged; how far back a public status page can display depends on the plan, from 30 days on the free plan to several hundred days above it. Deleting a monitor wipes all of its data.

Real-world use cases

Case 1: a deployment breaks the homepage

Symptom: a Friday evening deployment ships to production. On Monday morning, a customer reports that the contact form has been returning an error since the weekend.

Diagnosis: the check history shows a switch to down with 500 codes at 9:12 PM on Friday, then 61 hours of continuous downtime. The transition alert email was sent to an address nobody was reading.

Action: route alerts in the Monitoring category to a Slack webhook in addition to email, and add a dedicated monitor on the form endpoint rather than on the homepage alone.

Case 2: a false alarm from a regional network incident

Symptom: a DOWN alert arrives at 3 AM. The site responds normally from your machine.

Diagnosis: the monitor runs across three regions with the Strict strategy. The per-region breakdown shows timeout from the apac probe only, for 12 minutes, while eu and us return 200. This is not a site outage but a local transit incident.

Action: switch this monitor to Consensus, which requires at least half of the regions to fail. Keep Strict for endpoints where a regional flap is already a customer-facing incident, such as a payment API.

Case 3: a certificate expires on a Sunday

Symptom: the site has returned 200 for weeks, uptime sits at 100%, and yet browsers now display a security warning.

Diagnosis: automatic certificate renewal failed silently after a reverse-proxy configuration change. The uptime monitor flagged nothing before the expiry date: it only sees an invalid certificate once that date has passed, never in the weeks leading up to it.

Action: enable posture monitoring on this monitor. The expiry alert is sent at 30, 14, 7, 3 and 1 day, and the score drops as soon as the certificate or HSTS regresses.

How CaptainDNS compares to other website monitoring tools

CaptainDNS is not a specialized monitoring product: it is a DNS, SPF, DKIM, DMARC and blacklist dashboard that has since gained HTTP monitoring and security posture, with a data plane operated in the European Union. The choice therefore comes down to scope. If you only monitor uptime and need dozens of free monitors, a specialist such as UptimeRobot fits the need better. If you are after highly customizable status pages, BetterStack is more mature on that front. CaptainDNS makes sense when HTTP monitoring extends DNS and email monitoring you already run, and when European processing matters to you. Exact quotas and prices are on the plans and pricing page.

Quotas, limits and available plans

The free plan includes 1 HTTP monitor checked every 5 minutes from Europe, or 288 checks per day, with unlimited email alerts, 30 days of detailed history, the heatmap, p95 latency and 1 public status page, with no credit card. Paid plans raise the number of monitors, the number of regions you can enable, the retention window and the number of concurrent webhooks, and unlock posture monitoring from the Solo plan. The full grid is kept up to date on the plans and pricing page, which is the source of truth if it ever disagrees with this page.

European hosting, GDPR and data sovereignty

HTTP monitoring is a data processing activity: you send URLs, and sometimes authentication headers. CaptainDNS operates its data plane from the European Union, with European probes in France and Germany, a PostgreSQL database and backups in France, and a European technical team. The United States and Asia-Pacific probes are optional and only execute checks: results are sent back to the European database, which remains the primary store on every plan. The dashboard uses no tracking cookies and no third-party analytics scripts. You are the data controller for your monitors, and CaptainDNS acts as a processor under Article 28 of the GDPR; the DPA is available on request.

HTTP monitoring limitations

CaptainDNS HTTP monitoring does not cover the following needs:

• Raw TCP monitoring on non-HTTP ports (SMTP, FTP, database).
• Multi-step transactions: a user journey across several pages with successive assertions.
• Probes outside the three zones (Europe, United States and Asia-Pacific): no South America, Africa or Middle East.
• Non-public endpoints: a URL behind a VPN or a private firewall stays unreachable from our probes.

Slack, Discord, PagerDuty and Opsgenie alerts do not go through native integrations: you get them via HTTPS webhooks, leaving the destination to handle the final formatting.

FAQ - Frequently asked questions

Q: What is website monitoring?

A: Website monitoring means continuously checking the availability and latency of an HTTP URL. The tool sends a request at a regular interval, records the response, and triggers an alert on failure. That way an outage is detected before your users report it.

Q: How often does CaptainDNS check my URL?

A: By default, one HTTP check every 5 minutes on each of your monitors, or 288 checks per day. A cron expression lets you customize the cadence: a check every minute during business hours, or a maintenance window left out of the schedule.

Q: How do I receive an alert when my site goes down?

A: Turn email alerts on when you create the monitor: they go to your CaptainDNS account address, with no recipient to enter. As soon as a failure is confirmed (5xx, timeout, DNS error, invalid TLS certificate), an alert is sent. Reminders are then spaced at least an hour apart, and a recovery email closes the incident when the site comes back.

Q: What does 99.9% uptime mean?

A: An uptime of 99.9% leaves room for roughly 8 hours and 45 minutes of downtime a year, or 43 minutes a month. It is the threshold commonly targeted in production. At 99.99%, that budget drops to 52 minutes a year.

Q: Is CaptainDNS free for monitoring my site?

A: The free plan includes 1 HTTP monitor checked every 5 minutes, unlimited email alerts, the 30-day heatmap and p95 latency, with no credit card. Quotas for the other plans are detailed on the pricing page.

Q: Can I monitor an authenticated URL or a private endpoint?

A: Yes for public URLs. Custom HTTP headers (Authorization, X-API-Key) let you query a token-protected endpoint. A URL behind a VPN or a private firewall stays unreachable from our probes.

Q: How do I share my monitoring results?

A: Link your monitor to a public CaptainDNS status page. It exposes uptime, latency and incident history to your customers without giving them access to your private dashboard.

Q: What is the security posture score?

A: It is a score out of 100, recalculated periodically across five components: SSL/TLS certificate, HSTS, security headers, page weight and reputation (phishing). It splits into two areas, Security (80 points) and Performance (20 points). CaptainDNS alerts you whenever the score regresses, and before the certificate expires. Available from the Solo plan.

Q: Which components does the posture analyze, and how often?

A: SSL/TLS certificate, HSTS, HTTP security headers, page weight and reputation (phishing). You choose which components to track (at least one) and the scan frequency, from once an hour to once a day depending on your plan. Page weight and reputation are measured once a day at most.

Complementary tools

Useful resources

• Google SRE Book: Service Level Objectives (reference definition of SLAs, SLOs and the error budgets behind figures like 99.9%)
• RFC 6797 (HTTP Strict Transport Security specification, one of the posture score components)
• MDN: Content-Security-Policy (documentation on the CSP header and its directives)
• Let's Encrypt documentation (automatic renewal and lifetime of TLS certificates)
• CA/Browser Forum (the body that sets baseline requirements for public certificates, including their maximum validity period)
• Fly.io: regions (list of regions in the infrastructure the probes run on)