How to Set Up Page Speed Monitoring

Main Settings

This type has no dedicated screenshot for its Main Settings group, but every control in it is standard across HostTracker's monitor types:

• Domain/IP - the URL or domain to load. Accepts a full URL or a bare domain.
• Name - an optional label shown in your dashboard, alerts, reports and widgets. If left blank, the URL is used.
• Interval schedule / Cron schedule - a segmented toggle between a simple recurring interval and a full cron expression (hourly, daily, weekly, monthly presets, or advanced cron syntax). The minimum available interval depends on your plan.
• Tags - free-text labels for grouping and filtering this monitor.
• Full Log - saves every individual check result for this monitor without grouping them.
• Open Stats - lets you share this monitor's statistics and logs with others, including people who are not signed in.

This group also carries the Enabled toggle that pauses or resumes the monitor.

Page Configuration

• Device emulation - a dropdown that loads the page as a specific device would: viewport size, user agent string, and touch input emulation. The default is Desktop. The list of available devices is fetched live from the agent fleet's own capability set, so the exact options can grow over time; pick the device that best matches how your visitors browse the page.
• Page load timeout - the maximum time allowed for the page to finish loading, from 1 to 40 seconds. If the page has not finished by then, the check fails.

Both settings change what the numbers mean, as well as whether the check passes. A phone-sized viewport can trigger a different set of images, layout and scripts than a desktop viewport of the same page, so a mobile-emulated run's timing is not directly comparable to a desktop run - treat each device setting as its own baseline. The page load timeout is a ceiling, not a target: it only defines the point where the check gives up and reports failure. Setting it too close to your page's normal load time turns ordinary variance into false alarms; set it with margin and watch the actual load time in your results instead.

Response Validation

This is not a Core Web Vitals score - HostTracker is not computing a Lighthouse-style performance grade here. Instead it counts concrete browser-level failures and resource-usage limits, and you decide which of them should count as a Down. Every threshold below can be set to 0 (or, for CPU and memory, switched to "no threshold") to disable it.

Page health:

• Document/IFrame loading fail threshold - the check goes Down when at least this many documents or iframes on the page fail to load. Range 0-50; 0 disables it.
• CPU usage threshold - the check goes Down when the page's CPU usage (per core) reaches this percentage. The slider only covers 80-100%, so it catches heavy CPU spikes rather than ordinary load; a separate "no threshold" control turns it off entirely, which is the default.
• Memory usage threshold - the check goes Down when the page's memory usage reaches this amount, in megabytes. Range 1-1000 Mb in 50 Mb steps, or "no threshold" to disable, which is the default.
• Client-side errors threshold - the check goes Down when at least this many browser console errors occur while the page loads. Range 0-50; 0 disables it.
• Client-side warns threshold - the same idea for console warnings. Range 0-50; 0 disables it.

Content Load Checks:

• Page load timeout without XHR - an alternate, shorter timeout that applies once all the page's background XHR/AJAX requests have settled, separate from the main Page load timeout above. Set to 0 (the default), only the main page load timeout applies; a non-zero value lets you accept a page whose visible content is ready even while background polling continues.
• Total load fails threshold - the check goes Down when at least this many resources, of any kind, fail to load. Range 0-50; 0 disables it.
• Script / Stylesheet / Image / Font / AJAX request fails threshold - the same failure count, split out per resource type, so you can tolerate a flaky ad image without tolerating a broken script. Each is 0-50, 0 disables it.

Monitoring Locations

• Locations - a searchable checkbox tree of regions and individual monitoring points. Choose specific locations or leave "All world" checked.
• Recheck strategy - what happens when a check detects a state change. The default reruns the check from several locations and accepts the new state by majority vote, to guard against a false positive from one flaky location. Alternatives: a specified number of locations must confirm a Down (reveals a Down confirmations slider from 1 to 7); no recheck at all; full agreement of every recheck location; or full agreement for Down while Up only needs a majority.
• If selected locations are unavailable - "Selected locations only" (default) waits for your chosen locations to return; "Closest locations" substitutes the nearest available ones; "Any location" falls back worldwide.

Alert Subscriptions

A switch subscribes every contact to Up/Down events in one step, or a searchable table lets you subscribe individual contacts to Down, Up, and Repeat (repeated-Down reminders) independently. Leaving this section empty means no alerts will be sent for this monitor - the panel warns you explicitly if that is the case.

Report Subscriptions

The same pattern applies to uptime reports: a switch subscribes every contact to Weekly and Monthly reports, or you can pick Daily, Weekly and Monthly per contact individually.

Worked example

Say you want to watch how a checkout page performs for mobile shoppers. You would pick Page Speed, enter the checkout page's URL, and set Device emulation to a phone profile rather than Desktop, since most traffic on that page is mobile. Leave Page load timeout comfortably above the page's normal load time - it is a ceiling meant to catch genuine failures, not a performance target. In Response Validation, set the Document/IFrame loading fail threshold to 1, since the page commonly loads a payment iframe and you want to know if it stops loading. Leave CPU and Memory usage thresholds on "no threshold," since a checkout page is rarely CPU or memory intensive and those thresholds only start at 80% anyway. Set the Total load fails threshold to 2 or 3 rather than 0, so one flaky third-party tracker does not page your team every time it hiccups, while a genuinely broken load still trips the check. Leave Page load timeout without XHR at 0, since checkout pages often poll payment status in the background and that should not define pass or fail. Run the check from two or three locations near your actual customers, keep the default majority-vote recheck strategy, subscribe your on-call contact to Down and Repeat alerts, and set up a weekly report to a shared team address.

Troubleshooting

• The check reports Down but the page looks fine when you open it yourself. A load-fail counter (Script, Image, Total, and so on) most likely tripped on a flaky third-party resource, such as an ad network or analytics script, rather than your own page. Check which counter triggered before assuming a real outage, and consider raising it from 0 to 1 or 2 if that flakiness is a known, tolerable pattern.
• Load times changed noticeably after you switched Device emulation. Expected, not a regression: a different device profile changes the viewport, user agent and touch emulation, which changes what the page loads and how it renders. Compare timings only within the same device setting.
• The check keeps hitting the Page load timeout even though the page loads fine in your own browser. The monitoring location may be far from your server, or the timeout is measuring the full load including slow background requests. Raise the timeout with real margin, and if the page keeps polling in the background after its visible content is ready, try a non-zero Page load timeout without XHR.
• CPU or Memory usage thresholds never seem to fire, even on a heavy page. Both start on "no threshold," and the CPU slider only covers 80-100% once enabled. If tracking heavy resource usage matters, explicitly move the control off "no threshold" and pick a value in range.
• Console warnings from ad or analytics scripts keep tripping the Client-side warns threshold. Many third-party scripts log warnings that are not real problems. Leave this threshold at 0, or set it above your page's normal warning count.

Related

• Browser access timing monitoring - the product page for this check type.
• Free page speed test - run a one-off check before setting up ongoing monitoring.
• Transaction Check guide - for scripting a multi-step user journey rather than watching a single page load.
• Response validation rules - the rule language used for validating HTTP and API checks.
• How to check website speed - the one-off test, and what each timing number means.
• All monitoring guides - the setup guide for every other check type.