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, response content checks, and redirect handling can all be configured to match how your applications expect to be accessed. You can also group website monitors together, set up dependencies on other monitors to suppress related alert noise, and define user groups and third-party notification targets directly on the monitor.
Navigate to Synthetic → Web → Website and click the + icon to open the Add Website panel. Alternatively, navigate to the same view, select a monitor, and click Edit to modify its configuration.
The Add/Edit Website panel is organized into five collapsible sections: Monitor Details, Advanced Details, Content Checks, Configuration Details, and Alert Settings. Each section can be expanded independently.
Monitor Details: basic identification details for this website.
| Field | Description |
| Probe* | The probe through which this website should be monitored. |
| Display 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 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. |
Advanced Details: advanced request, timeout, SSL, and response settings.
| Field | Description |
| Connection Timeout (sec)* | Maximum time in seconds to wait for a response before marking the check as failed. |
| User Agent | Simulates a specific browser or client. 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. Click the + icon to add a header. |
| 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. |
Content Checks: configure string matching and HTTP header verification rules to validate the response content, not just the status code.
| Field | Description |
| Should contain string(s) | One or more strings that must be present in the response body for the check to be considered successful. Useful for confirming a specific keyword, product name, or status message appears on the page. |
| Should not contain string(s) | One or more strings whose presence in the response body marks the check as failed. Useful for catching maintenance pages or error banners that still return a 200 status code. |
| Case Sensitive | When enabled, the string and header checks above are matched case-sensitively. |
| Should match regular expression | Marks the check as failed unless the response body matches the given regular expression. |
| Should not match regular expression | Marks the check as failed if the response body matches the given regular expression. |
| Should contain HTTP Request Header(s) | Verifies that the response includes specific headers (and optionally specific values). Useful for confirming caching, security, or content-type headers are present. Click the + icon to add a header to check. |
Configuration Details: interval, groups, dependencies, and tagging options.
| Field | Description |
| Interval* | How frequently the URL is polled and statistics are reported. |
| Groups | Optional groups this monitor should belong to, making it easier to organize related monitors and apply common settings, such as alarm rules or reports, across all of them at once. |
| Depends On | An optional parent monitor (for example, a network node or another website) that this monitor depends on. If the parent is unavailable, alerts for this monitor are suppressed, reducing notification noise during related outages. |
| Tags | Optional labels for grouping and filtering monitors. |
Alert Settings: configure alerting rules for this monitor.
| Field | Description |
| Alarm Rule | The alarm rule profile to apply to this monitor, defining the metrics, thresholds, and severities that trigger an alert. Alarm rule profiles are created separately under Settings → Configurations → Alarm Rules; this field attaches an existing profile to the monitor. |
| User Groups | The user groups that should be notified when an alarm is raised for this monitor. |
| Third Party Services | Third-party integrations (such as Slack, Teams, or ITSM tools) to notify when an alarm is raised for this monitor. User Groups and Third Party Services set here at the monitor level are automatically inherited by any alarm rule applied to the monitor, so notification routing does not need to be repeated on every rule. |
Click Save to add or update the monitor. Click Reset to clear the form, or Close to dismiss the panel without saving.
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 rule is built around a simple IF/THEN model, where you select a metric, set a threshold, and define what happens when it is breached. Alarm rule profiles for website monitors, covering metrics such as Website Response Time, Availability, Status Code, Content Check, and Header checks, are created under Settings → Configurations → Alarm Rules. Learn more.
To apply an alarm rule to a specific website, open the website's Edit panel and select the desired profile from the Alarm Rule field under Alert Settings. From the same section, you can also assign the User Groups and Third Party Services that should be notified. These are inherited automatically by the attached alarm rule, so the notification routing only needs to be set once per monitor.
In addition to the standard HTTP check, Cloudmon supports browser-based webpage load monitoring. This uses a real browser engine to load the full page, including all JavaScript, CSS, images, and third-party resources, and measures the complete rendering experience as a user would see it.
The distinction from standard Website monitoring is scope. A standard website check measures whether the server responded and how quickly. Webpage Load monitoring measures the full page render time, which includes JavaScript framework execution, third-party script loading, image rendering, and any dynamic content that only appears after the initial HTML is returned. A page can return a 200 status code in 300ms and still take 8 seconds to become usable for the end user.
Webpage Load monitoring captures:
Lighthouse Analysis: Cloudmon runs a Lighthouse-based audit against the monitored page at each polling interval, producing scored assessments across Performance, Accessibility, Best Practices, and SEO. Each score is derived from underlying audits covering key Web Vitals metrics such as Largest Contentful Paint (LCP), Total Blocking Time (TBT), Cumulative Layout Shift (CLS), and Time to Interactive (TTI). This gives a structured view of where the page is underperforming against web standards, not just how long it took to load.
HAR Analysis: For each poll, Cloudmon captures a full HTTP Archive (HAR) record of every network request the browser made while loading the page. The HAR viewer displays a waterfall chart covering all request types, including HTML, CSS, JavaScript, images, fonts, and third-party calls, with each request showing its start time, duration, size, and status code. This makes it straightforward to identify which resource is blocking the render path, which third-party script is adding latency, and which assets would benefit from caching or compression.
To configure a Webpage Load monitor, navigate to Synthetic → Web → Webpage Load and click the + icon to add a new monitor with the target URL. Configured monitors are also listed in the same view. Alarm rules are attached the same way as for Website monitors, under the monitor's Alert Settings section, and support thresholds on Page Load Time and availability.
| 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 under Advanced Details 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 under Advanced Details. 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 under Advanced Details. A 5xx means the server is erroring during the probe request, which should be investigated at the application level. |
| Page returns a 200 but should be treated as a failure (e.g. a maintenance page) | Use the Content Checks section to add a "Should not contain string(s)" rule for text that only appears on the maintenance or error page, or a "Should contain string(s)" rule for text that should always be present on a healthy page. |
| Website monitor was added but is not appearing under Synthetic | Check that all required (*) fields in Monitor Details, including Probe and Connection Timeout, were filled in before clicking Save. Once saved, the monitor will appear under Synthetic → Web → Website. |