Track availability, response time, and connection performance for any URL. Cloudmon polls your websites at regular intervals, checks HTTP status codes, and measures the full connection breakdown from DNS lookup through to content download so you can pinpoint exactly where slowdowns occur.
Website monitoring in Cloudmon actively requests a URL at every polling interval and records whether it responded successfully, how long it took, and the full breakdown of the connection lifecycle. This lets you distinguish between a DNS resolution problem, a slow SSL handshake, a slow server response, and slow content delivery, rather than seeing only a single total response time number.
Any URL accessible from a Cloudmon probe can be monitored. This includes public-facing websites and landing pages, internal web applications and admin portals, REST APIs and webhook endpoints, and any service that responds to HTTP or HTTPS requests. Custom HTTP headers, user agent strings, and redirect handling can all be configured to match how your applications expect to be accessed.
Navigate to Settings → Monitoring → Probes, select the probe from which the website should be monitored, go to the Website tab, and click Add. Alternatively, navigate to Synthetic → Web →Website to view all monitored websites. Fill in the add form as follows:
| Field | Description |
| Name | A descriptive label for this URL monitor, such as "Company Homepage" or "Customer Portal Login". |
| Website URL | The full URL to monitor, including the protocol, for example https://app.company.com/login. For APIs, this can be any endpoint that responds to the configured method. |
| Method | Choose GET to retrieve the full page content, or HEAD to check availability without downloading the response body. HEAD is more efficient for high-frequency monitoring of large pages. |
| User Agent | Simulates a specific browser or client. Options include Chrome on Windows, Edge on macOS, Opera on Linux, and others. Use a user agent that matches how your application is primarily accessed. |
| HTTP Request Headers | Key-value pairs sent with each request. Useful for adding Authorization tokens, Content-Type, custom host headers, or any other headers required by the monitored application. |
| Follow Redirection | Enabled by default. When on, Cloudmon follows HTTP redirects automatically and reports on the final destination. Disable if you want to detect unexpected redirects as failures. |
| Trust Server SSL Certificate | Enabled by default. Disable for internal services using self-signed certificates where SSL validation would cause false-positive failures. |
| Connection Timeout | Maximum time in seconds to wait for a response before marking the check as failed. |
| Interval | How frequently the URL is polled and statistics are reported. |
| Tags | Optional labels for grouping and filtering monitors. |
Click Save. Navigate to Synthetic → Website to view the monitor in the website list.
The website list shows each monitored URL with its current status code, availability status, response time, and last polled time. Clicking into a monitor opens the full detail view with six metrics in the summary panel: Availability as a percentage, Downtime duration, Response Time in milliseconds, Status Code from the last successful check, Throughput as the data transfer rate, and Redirections as the count of HTTP redirects followed to reach the final URL.
The Log Report tab provides a per-poll breakdown of every connection metric, including HTTP Status Code, DNS Response Time, Connection Time, SSL Handshake Time, First Byte Time, Download Time, total Response Time, Resolved IP, Stalled Time, and Content Length. This breakdown makes it possible to pinpoint exactly which stage of the connection is slow. For example, a high SSL Handshake Time on an e-commerce checkout page indicates a TLS configuration issue, while a high First Byte Time points to a slow application server response rather than a network problem.
The View Headers button in the detail page shows the full request and response headers for the last check, useful for verifying that the correct cache control, content type, and security headers are being returned.
Each alarm is built around a simple IF/THEN model, where you select a metric, set a threshold, and define what happens when it is breached. Learn more.
To configure an alarm for a specific website, navigate to Synthetic → Web →Website → [Select Website] → Settings → Alarm Rule and click Add Trigger. Available metrics include Website Response Time, Availability, Status Code, Content Check, and Header checks. For example, you can alert when response time exceeds 3,000 milliseconds for 2 consecutive intervals, or immediately when a non-200 status code is returned.
| Issue | What to check |
| Website shows as down but is accessible in a browser | Check whether the site requires a specific User Agent to respond correctly. Some applications return a 403 or block requests from non-browser user agents. Set the User Agent in the monitor settings to match the browser the site is built for. Also verify that Follow Redirection is enabled if the URL performs a redirect before serving content. |
| SSL-related error causing the monitor to fail | If the monitored site uses a self-signed or internally signed certificate, disable the Trust Server SSL Certificate option in the monitor settings. This prevents the probe from rejecting the connection due to a certificate it cannot validate against a public CA chain. |
| High response time but the site feels fast in a browser | Review the Log Report tab to identify which stage of the connection is slow. A high DNS Response Time means the probe is experiencing DNS resolution delays that a local browser would not, because browsers cache DNS results. A high SSL Handshake Time indicates a TLS configuration issue on the web server. A high First Byte Time points to a slow application response independent of network conditions. |
| Monitor returns a 4xx or 5xx status code unexpectedly | A 401 or 403 usually means the request is missing an Authorization header or the probe IP is blocked by the application. Add the required Authorization header in the HTTP Request Headers field of the monitor settings. A 5xx means the server is erroring during the probe request, which should be investigated at the application level. |
| Website monitor was added but is not appearing under Synthetic | Websites must be added from the probe's Website tab under Settings rather than directly from the Synthetic section. Navigate to Settings → Monitoring → Probes, select the correct probe, open the Website tab, and confirm the URL was saved there. The monitor will then appear under Synthetic → Website. |