Skip to content
Go to dashboard

15.3Allowing our checks through your firewall

obsrvly does not publish a list of IP addresses. Checks run from each region you choose for a monitor (3.2). Their addresses can change, so do not allow checks by IP address.

Instead, send a header token: a secret value in a request header. Your firewall then lets in requests that carry it.

Set up a header token#

  1. Choose a long random value for the token.
  2. In the dashboard, save it as a team secret, for example MONITOR_TOKEN (8.2). Names use A–Z, 0–9 and _, start with a letter, and have at most 64 characters.
  3. Under allowed sites, enter the site your monitor checks, for example app.example.com. You can also create the secret with its allowed sites through the API (CreateSecret). To change the sites later, use the dashboard. An API key cannot change them (8.5).
  4. Create an API monitor (2.3) or a multi-step API monitor (2.4).
  5. In the headers section, select + add header. Enter a header name and the value ${MONITOR_TOKEN}. In a multi-step monitor, add the header to each step that needs it.
  6. On your firewall or server, allow requests that carry this header with your token's value.
Example header
X-Monitor-Token: ${MONITOR_TOKEN}

X-Monitor-Token is only an example. Use any header name your firewall can check.

Other check types#

TCP, UDP, DNS, ping and gRPC checks cannot send headers. They come from the regions you choose.

Heartbeats need no firewall rule for obsrvly. Your job calls obsrvly, not the other way round (chapter 5).

Webhooks to your server#

You can use the same header token on a webhook channel (chapter 11). A webhook can have at most 50 custom headers. Also check the webhook signature (11.4).

If the check still fails#

If the result says "destination is not a publicly routable address", the address is private. A firewall rule cannot fix this. See 15.1.

Last updated