Monitoring infrastructure documentation
Uptime.com Monitoring Bot
Uptime.com LLC operates a globally distributed network of monitoring probes that check the availability and performance of websites, APIs, and online services on behalf of our customers.
This page describes why the probes make automated requests, how they operate, what information they collect, and how website operators can identify legitimate Uptime.com monitoring traffic.
At a glance
- Operator
- Uptime.com LLC (Uptime.com)
- Purpose
- Customer-configured service availability, performance, and synthetic monitoring
- User-Agent identifier
Uptime/(includingUptime/1.0andUptime/2.0)- Source IPs
- Published probe IP list (IPv4 and IPv6)
Purpose of the monitoring bot
Uptime.com customers configure checks to verify that their websites and services are reachable and behaving as expected. Our probes execute those checks from selected locations and report the results to Uptime.com so customers can investigate failures, review performance, and receive alerts about outages or recovery.
Checks can validate HTTP responses, measure response times, test API endpoints, and exercise customer-defined browser transactions. Our probes are not autonomous web crawlers: they do not discover sites to index for search engines, build advertising profiles, or collect website content for AI model training.
How monitoring probes operate
- A customer configures a check, including its target URL or service, check type, interval, monitoring locations, and any validation criteria.
- Uptime.com schedules the check on the applicable monitoring probes, which initiate requests to the configured endpoint.
- For HTTP(S) checks, a probe sends an HTTP request and evaluates the response. Depending on configuration, requests can include specific methods, headers, authentication, or payloads supplied by the customer.
- For browser-based synthetic monitoring, a probe may load page resources, execute JavaScript, and follow a customer-defined sequence of interactions to verify a user journey.
- The check results are processed by Uptime.com to display availability and performance information, maintain monitoring history, and generate alerts according to the customer's settings.
Request frequency and target selection are determined by the customer's configuration. Different monitoring check types collect different technical measurements; not every check uses an HTTP User-Agent.
What information do our probes collect?
Probes gather technical information needed to evaluate each customer-configured check. Depending on the check type and its settings, this can include:
- Availability and response results: HTTP status codes, success or failure states, timeouts, and connection errors.
- Performance measurements: response times and relevant connection or page-loading timings.
- HTTP validation data: response headers and response content necessary to assess customer-defined conditions.
- Connection diagnostics: DNS resolution outcomes, TLS/certificate information, and related network errors.
- Synthetic transaction results: browser execution outcomes and, when supported by the configured check, diagnostic artifacts such as screenshots.
The data processed depends on what the customer chooses to monitor and how the target service responds. Uptime.com uses check results to provide monitoring dashboards, alert notifications, reporting, and troubleshooting. Monitoring data is handled in accordance with our Privacy Policy and applicable service agreements.
How to identify Uptime.com monitoring traffic
User-Agent
Our standard HTTP monitoring User-Agent contains the Uptime/ identifier. Our legacy and next-generation check engines use versions such as:
Mozilla/5.0 (compatible; Uptime/1.0; http://uptime.com)Mozilla/5.0 (compatible; Uptime/2.0; http://uptime.com)
Browser-based checks can use a longer browser User-Agent that includes the same identifier. Customers may also configure a custom User-Agent for certain checks, so an identifier alone is not definitive proof of origin.
See How to Identify the Uptime.com User-Agent for current examples.
Probe IP addresses
Uptime.com publishes the source IP addresses for its global monitoring infrastructure. These can change as locations and infrastructure are added or migrated.
Current probe IP list: https://uptime.com/api/v1/probe-servers/ips/
Website operators should use both the observed source IP and other relevant request characteristics when identifying monitoring traffic. User-Agent strings can be imitated and are not sufficient proof of identity on their own.
Monitoring traffic and security filters
Content delivery networks, web application firewalls (WAFs), and bot protection services may challenge or block legitimate automated monitoring requests. For example, an HTTP 403 response may occur even when a website works normally in a browser.
If monitoring requests are blocked, website administrators or their hosting providers can review security events and, when appropriate, configure their protections to recognise Uptime.com monitoring traffic. The source IP list and User-Agent documentation above can help with that investigation.
See How to Whitelist Uptime.com Probe Servers and User Agents for guidance.
Uptime.com Analyzer
Uptime.com LLC also operates Uptime.com Analyzer, a separate automated service that examines websites provided by customers to identify relevant pages and endpoints and help recommend or create suitable monitoring checks.
Unlike the scheduled monitoring probes described above, Analyzer requests are made for website analysis rather than continuous availability monitoring. Depending on the website being analyzed, information used for these recommendations may include discovered URLs, HTTP response status codes, response headers, relevant page content, and technical characteristics of the endpoints. This information is used to identify and configure appropriate monitoring checks, not to index websites for search engines or build advertising profiles.
Analyzer traffic uses the UptimeAnalyzer/ User-Agent identifier, for example Mozilla/5.0 (compatible; UptimeAnalyzer/1.0; http://uptime.com). This is distinct from the Uptime/ User-Agent used by our monitoring probes.
Analyzer's request identity method is Web Bot Auth (HTTP Message Signatures). Verification keys are published in our HTTP Message Signatures directory. This is separate from the IP-list-based identity method documented above for monitoring probes.
Questions about monitoring traffic?
If you see Uptime.com requests in your access logs, a site administrator, service provider, or other customer may have configured a check for that endpoint. For help identifying traffic or investigating an unexpected request, contact support@uptime.com.
Bot operator: Uptime.com LLC | Website: uptime.com