A website can go offline overnight, respond more slowly after a deployment, or become inaccessible when its certificate expires. Opening it occasionally gives you a snapshot. Website monitoring regularly checks whether a URL is available, how quickly it responds, and how long its TLS certificate remains valid.
This guide shows you how to monitor your website with MetriBeacon, interpret the results, and configure alerts you can act on.
What is website monitoring?
A monitoring service requests a public HTTP or HTTPS URL at regular intervals. It compares the response with your expectations and records the history. Regular availability checks are also called uptime monitoring.
For a small business website, the homepage is often a useful starting point. For an API, a dedicated health endpoint may provide a better signal. What matters is what that endpoint actually checks: HTTP 200 confirms that the request succeeded, but does not automatically prove that a shopping cart works or a database is accessible.
Understand these four signals
- HTTP status code: Shows the response returned by the server. A misconfigured error page can also return HTTP 200.
- Availability: Shows whether the configured check succeeded. It applies to the endpoint and times actually observed.
- HTTP response time: Makes changes in request duration visible over time. It does not measure the complete browser page load.
- Certificate lifetime: Warns of an approaching TLS certificate expiry. It does not prove that automatic renewal will succeed.
Response time and page load time are different measurements. An HTTP check observes a single request. Images, additional JavaScript files, and browser rendering are not a complete part of this monitor’s test. Add browser measurements to understand the loading experience your visitors receive.
A status such as 503 indicates that the server cannot currently handle the request. Always check your configured expectation: an endpoint deliberately returning 204 should not be marked as unhealthy simply because you expected 200. The MDN HTTP status reference explains the individual responses.
Set up website monitoring with MetriBeacon
1. Choose a useful URL
Choose a public HTTPS URL that represents the service your visitors use. For a website, start with the homepage or an important information page. For an API, use a health endpoint whose checks you understand.
The public HTTP checker cannot reach private networks, localhost, or internal NAS addresses. Use the Linux agent or HTTPS API for observations from private infrastructure. You do not need to install an agent on the target of a public website check.
2. Open the Website/API template
Create a free account or sign in. Open the Website/API template in the dashboard and select a workspace. If you do not have one, you can create it in the template flow.
Give the monitor a clear name, such as “Business website”, and enter your URL. The template uses GET, expects HTTP 200, and checks every 300 seconds. Review these settings rather than applying them to every endpoint without checking.
3. Review the interval and expected response
Five minutes is a possible starting point for a simple website. HTTP monitoring supports intervals between 60 and 3,600 seconds. A shorter interval provides more observations and creates more requests and measurement data.
With GET, you can check the status, included text, or a top-level JSON value. HEAD checks only the status. See the HTTP monitoring guide for the settings.
There is an important limitation: a short interruption between two five-minute checks may go unobserved. The interval is not a guarantee of immediate detection.
4. Confirm the preview and inspect the first values
Review the preview, including your selected alert suggestions, and explicitly create the monitor. Open it and wait for the first scheduled check.
The monitor provides series for status code, response time, certificate days remaining, and availability. A newly created monitor with no observations is not evidence of an outage. Once values arrive, check that the expected response matches what your URL actually does.
Configure useful alerts
An alert should lead to a specific action. Before enabling it, decide who receives the message, what they will check first, and when the problem counts as resolved.
Monitor availability
Enable an availability rule for confirmed target failures. When it fires, check the endpoint, recent deployments, and server logs first. A working homepage still does not replace a test of login, checkout, or other business operations.
Renew TLS certificates in time
The website template offers a certificate alert when fewer than 14 days remain. Choose a warning period that fits your renewal process, and inspect the new measurement after automatic renewal as well. The familiar term “SSL certificate” refers here to the certificate used for your HTTPS site’s TLS connection.
Evaluate response times against your history
First observe what is normal for your endpoint. If a request usually takes around 200 milliseconds, recurring increases to several seconds deserve investigation. These numbers are an example, not measurements of your website.
If you configure a threshold alert, choose a suitable firing duration and a separate clearing threshold. Small fluctuations around the boundary then do not keep switching the alert on and off. The alerts guide explains the setup.
Connect email or Telegram and check delivery with a test message. Configure maintenance windows for planned interruptions. A saved alert without a working delivery channel offers little help during an incident.
“Unknown” does not mean “down”
A confirmed website failure is different from a missing observation. An unavailable checker, DNS timeout, quota pause, or missing required headers can result in an unknown or paused state.
Read the time range, data coverage, and state together. A gap should count as neither a successful request nor a confirmed outage. Monitoring provides clues for diagnosis; additional observations and logs help you establish the cause.
Reproduce a single request with curl
If a check looks unusual, request the public URL from your own computer as an additional observation. This example prints the final HTTP status and total request duration in seconds:
curl --silent --show-error --location --max-time 10 \
--output /dev/null \
--write-out 'HTTP %{http_code}\nDuration %{time_total} s\n' \
https://example.com/
Replace the example address with your own public URL. The command follows redirects and limits the request to ten seconds. It prints HTTP error statuses; curl reports transport errors separately. The result may differ from the monitor because your computer uses a different network path. A single request does not replace regular monitoring. The official curl manual documents these options.
Website monitoring FAQ
Is website monitoring with MetriBeacon free?
Yes, you can use MetriBeacon for free within its technical quotas. The free monitoring overview lists the limits for monitors, series, and data intake. Your account shows your current usage.
Does an HTTP check measure my page load time?
It records the response time of the monitored HTTP request. Measuring the complete load, including all resources and browser rendering, requires an additional browser measurement.
Can I check an internal website or a NAS?
The public HTTP checker does not connect to private network addresses. Collect internal observations locally and send them through the HTTPS API. The Linux agent is also available for server measurements.
How quickly will an outage be detected?
This depends on the check interval, when the outage starts, and confirmation of the failure. A short interruption between checks may remain undetected. Notifications also require a configured and reachable delivery channel.
Checklist for your first website monitor
- Your URL is publicly reachable and represents the service you want to observe.
- The method, expected status, and any content check match the endpoint.
- You have deliberately chosen the interval and checked the first measurements.
- Availability and certificate alerts are explicitly enabled.
- A test message reaches the intended recipient.
- Maintenance windows are planned for scheduled work.
Start with one important URL and add further checks when you can put their results to use. The button below this article takes you directly to the matching Website/API template.
