Monitoring

    Custom Request Headers

    Send custom HTTP headers with every check — bearer tokens, User-Agents, host overrides. Validated as JSON, 4 kB cap.

    Updated 2026-06-15
    2 min read
    headers
    authentication
    bearer

    Custom Request Headers#

    Send extra HTTP headers with every check so LemWatch can reach endpoints that need authentication, a specific User-Agent, or a host override.

    Format#

    A JSON object — keys are header names, values are strings.

    {
      "Authorization": "Bearer eyJhbGciOi...",
      "User-Agent": "LemWatch-Probe/1.0",
      "X-Forwarded-Host": "api.example.com"
    }

    Rules#

  1. Must be valid JSON parsable as an object (not an array, not a bare string)
  2. Max 4,000 characters total
  3. Header names and values are sent verbatim — no escaping applied
  4. Empty string "" is treated as "no custom headers"
  5. Common patterns#

    Protect a staging environment

    { "Authorization": "Basic dXNlcjpwYXNz" }

    Allowlist past your WAF

    { "X-LemWatch-Probe": "your-shared-secret" }

    Pin a CDN edge

    { "Host": "origin.example.com" }

    Security#

    Headers are stored encrypted at rest. They are visible in the audit log to admins of your organization. Rotate any token if a teammate leaves.

    Troubleshooting#

  6. "Custom headers must be a valid JSON object" — your value is missing braces, has a trailing comma, or is an array
  7. Auth header ignored — confirm the upstream actually accepts the header name (some WAFs strip Authorization)
  8. Headers gone after save — make sure you're on the latest build; older releases dropped this field due to a Zod schema gap
  9. Was this article helpful?