The recommended way to permit Uptime Basics is a public, purpose-built health endpoint protected by a dedicated custom request header or HTTP Basic Authentication. Scope the exception to that endpoint instead of disabling security controls for the entire website.
Uptime Basics does not currently publish fixed source IP addresses for customer allowlists. Monitoring runs from multiple cloud regions and the outbound addresses can change, so an IP copied from a log is not a stable product identity.
Paid availability requests identify themselves with the HTTP user agent UptimeBasics/1.0 (+https://uptimebasics.com). You can use this value to recognize monitoring traffic in logs or as one condition in a narrow rule. Do not treat a user agent as authentication because another client can copy it; use a dedicated secret header or Basic Authentication when the endpoint needs an access control.
Before you begin
Only change firewall, CDN, WAF, or application rules for a website you are authorized to administer.
Choose an endpoint that:
- is reachable through public HTTP or HTTPS on port 80 or 443;
- returns no customer information or operational secrets;
- does not require JavaScript, CAPTCHA, cookies, or an interactive login;
- can answer quickly with a clear healthy or failed status; and
- represents enough of the application to be useful.
An example path is /health/uptime, but a hidden path alone is not authentication.
Recommended method: a dedicated custom header
- Generate a long, random value used only by this monitor.
- Configure your edge or application rule to match the exact health path.
- Require a dedicated header such as
X-Uptime-Monitor-Keywith that value. - Allow the matched request to bypass only the specific rule that blocks monitoring.
- In Uptime Basics, open Advanced Request Options.
- Add the same header name and value under Custom request headers.
- Save the monitor and review the next checks in Detailed Logs.
You can configure up to 10 supported custom headers. Use one narrow header whenever possible rather than creating a complex exception.
The monitor sends a saved custom header to the configured origin and through redirects on that same origin. Sensitive request settings are removed when a redirect changes to another origin.
Alternative: HTTP Basic Authentication
Use Basic Authentication when the endpoint already supports standard HTTP Basic credentials.
- Create a dedicated least-privilege username and password.
- Limit that account to the health endpoint.
- Select Basic Authentication in the monitor settings.
- Enter the dedicated username and password.
- Save and confirm the result in Detailed Logs.
Do not reuse an administrator password. Uptime Basics does not support form-based login, browser sessions, CAPTCHA, or interactive multi-factor authentication.
Header restrictions
For safety and request integrity, customer-defined values are not accepted for:
AuthorizationConnectionContent-LengthCookieHostProxy-AuthorizationTransfer-EncodingUpgrade
Use the dedicated Basic Authentication setting instead of entering an Authorization header. Do not place a password, token, or allowlist value in the URL or query string.
Saved supported request secrets are encrypted and are not returned to the browser in plaintext.
Why broad AWS or IP allowlists are not recommended
Do not allow all cloud-provider address ranges. Those ranges are shared by many unrelated customers and services and would create a much broader exception than Uptime Basics requires.
Do not permanently allow an address observed in one request log. A later check or a regional confirmation request may use a different address.
If your security product supports only fixed source-IP allowlists and cannot match a path plus a secret header, fixed-IP allowlisting is not currently a supported Uptime Basics integration. Keep the endpoint publicly reachable with a narrow application-level control, use a supported authentication option, or contact Support before weakening a network rule.
Configure common security layers
The exact interface differs by provider, but the rule should follow the same principle:
| Layer | Narrow rule |
|---|---|
| CDN or WAF | Match the exact host and health path, then require the dedicated header |
| Reverse proxy | Route only the health path and validate the header before forwarding |
| Web server | Permit the health route without opening unrelated files or directories |
| Application | Validate a dedicated monitor credential and return a minimal response |
| Rate limiter | Give the health route enough capacity for the selected interval without exempting the whole site |
Keep logging enabled. Redact the dedicated secret from logs, traces, and error pages where your provider supports redaction.
Rotate an allowlist value safely
- Make the endpoint temporarily accept both the old and new values.
- Replace the saved value in the monitor.
- Confirm successful checks from the primary and any confirmation regions.
- Remove the old value from the endpoint.
- Confirm the next scheduled check remains healthy.
This overlap prevents a monitoring gap while the setting changes.
Troubleshooting
HTTP 403: Review which firewall, CDN, WAF, bot, geographic, or application rule rejected the exact request.
HTTP 401: Confirm Basic Authentication is selected and that the dedicated credentials are active.
HTTP 429: Review the selected interval and the rate-limit group applied to the health path.
Timeout with no HTTP code: Check whether a network rule silently drops the request instead of returning a denial.
Only some regions fail: Apply the intended rule consistently wherever the hostname can be served, while considering whether real customers in those regions should also have access.
When contacting Support, include the monitor name, URL, timestamps, affected regions, diagnosis, and sanitized rule names. Never include the header value, password, session cookie, private key, or complete firewall configuration.