Uptime Basics protects saved Basic Authentication passwords and custom request-header values at rest, does not return their plaintext values after saving, and uses them only when making the monitor's approved request.
You are still responsible for choosing limited-purpose credentials, using HTTPS, and rotating access when it is no longer needed.
Which monitor settings can contain secrets
Treat these as sensitive:
- A Basic Authentication password.
- A custom header value used as an API key, allowlist key, token, or shared secret.
- A username when it reveals an internal account or system identity.
Do not put any secret in a monitor name, URL, query string, status-page text, support message, or another field intended for display.
Uptime Basics rejects URLs with embedded credentials. Use Basic authentication under Advanced Request Options instead of a URL such as https://user:password@example.com.
Protection while saved
Production monitor request secrets are encrypted at rest and bound to the monitor and customer account that saved them. The monitoring worker decrypts the protected values only when it needs to construct an authorized request.
The customer API does not return the saved Basic Authentication password or custom-header values in plaintext. The interface can still show safe metadata such as:
- The custom header name.
- Whether a value is already saved.
- The selected authentication type.
- The Basic Authentication username.
- Whether a password is already saved.
This is why an existing password or header-value field can appear blank even though the monitor continues to use the saved value.
Keep, replace, or remove a saved value
When editing an existing monitor:
- Leave a saved secret field blank to keep its existing value.
- Enter a new value to replace the saved value.
- Remove the header row and save to remove that header.
- Select No authentication and save to remove Basic Authentication.
Uptime Basics cannot display the old secret so you can copy it. If the original value is lost, create a replacement at the protected service, update the monitor, confirm a successful check, and revoke the old value.
Protection while the check is sent
Use HTTPS whenever a request contains credentials. HTTP Basic Authentication encodes credentials but does not encrypt the network connection; HTTPS provides transport encryption.
Request settings follow redirect boundaries:
- Same-origin redirects can continue using the saved Basic Authentication and custom headers.
- When a redirect changes to a different origin, Uptime Basics removes those sensitive request settings.
This prevents a credential intended for one site from being forwarded to an unrelated destination. If the final approved origin also requires access, monitor that final URL directly and configure only the credentials intended for it.
Where saved secrets do not appear
Saved request-secret values are excluded from:
- Detailed Logs and CSV exports.
- Incident pages and incident JSON exports.
- Customer public status pages and their snapshots.
- Routine technical-support views.
Check results can still show safe evidence such as an HTTP code, timing, diagnosis, redirect outcome, and header names where relevant. Avoid placing secrets in URLs because URLs can legitimately appear in monitoring records and exports.
Authorized support access
Routine technical-support tools mask saved request secrets. Authorized support staff can review safe monitor configuration, check results, incidents, diagnostics, and alert history when reasonably required to answer a support request.
Privileged views and changes are logged, and a reason is required before support saves a monitor change. Support does not need your plaintext password, API key, token, Cookie value, or authorization value to review a monitoring problem.
Recommended credential practices
- Create a dedicated monitoring identity or secret.
- Grant access only to the exact health endpoint or resource needed.
- Use HTTPS.
- Keep the endpoint read-only and avoid administrator permissions.
- Rotate the secret when staff, vendors, or systems change.
- Revoke it when the monitor is removed or access is no longer needed.
- Review your application and gateway logs for unexpected use.
Do not reuse a normal administrator password or a credential that can modify production data.
If you believe a credential was exposed
Revoke or rotate it at the protected service immediately. Then update the monitor with the replacement and review access logs at that service.
Contact Uptime Basics Support with the monitor name, approximate time, header name or authentication type, and the action you took. Do not send the exposed or replacement value.