Skip to main content
Uptime Basics logo
Monitors

Add custom request headers

Add secure custom HTTP headers for allowlisted health endpoints, test routes, and applications that expect a specific request value.

Article MON-008 By Uptime Basics Support Reviewed July 21, 2026

Custom request headers let a monitor identify itself to your application or supply a value expected by a dedicated health endpoint. They are useful for allowlisting, routing test traffic, selecting a response format, or checking an endpoint that expects a non-interactive request header.

Add a request header

When creating a monitor:

  1. Open New Monitor and find Advanced request options.
  2. Enter the header name, such as X-Monitor-Key.
  3. Enter the value expected by your application.
  4. Select Add header if another row is needed.
  5. Finish the settings and create the monitor.

For an existing monitor, open Advanced Request Options, edit the header rows, and save the changes.

You can save up to 10 custom headers on one monitor. Header names can contain standard HTTP header-name characters and are treated as case-insensitive, so duplicate names are not added twice.

Headers that cannot be added

Uptime Basics does not accept customer values for connection-controlled or high-risk headers:

  • Authorization
  • Connection
  • Content-Length
  • Cookie
  • Host
  • Proxy-Authorization
  • Transfer-Encoding
  • Upgrade

Use the monitor's Authentication setting for HTTP Basic Authentication instead of creating an Authorization header.

Protect header values

Use a dedicated, limited-purpose value rather than a production administrator credential. Saved request settings are protected at rest, and saved values are not returned to the browser after secure storage is enabled. When an existing value is shown as saved, leave it blank to keep it or enter a replacement value.

Custom headers are sent to the configured origin and through redirects on that same origin. They are removed when a redirect changes to another origin so a credential or allowlist value is not disclosed to an unrelated destination.

If the header does not work

Check the spelling and capitalization expected by your application, confirm that the value has not expired, and verify that your CDN or proxy forwards the header to the endpoint. If the application redirects to another origin, monitor the final approved endpoint directly or configure that endpoint separately.

The monitor is an HTTP client, not a browser automation session. Custom headers do not complete JavaScript login flows, cookie consent, CAPTCHA, or interactive multi-factor authentication.

If the request is still rejected, review the HTTP code in Detailed Logs and contact Uptime Basics support without sending the header's secret value.

Related articles

Did this answer your question?

Your response helps improve this Help Center.