Our monitoring probe

Our checks send this User-Agent:

Match on Sentivel-Monitor rather than the whole string. The browser portion tracks Chrome and will change; the name will not.

Checks are HTTP requests to the URL you gave us, on the interval you set. We follow redirects, read at most 1 MB of the response, and never execute JavaScript.

Every check carries an HTTP Message Signature (RFC 9421, the Web Bot Auth profile). We sign it with an Ed25519 key and publish the public half at /.well-known/http-message-signatures-directory.

This is stronger than matching a User-Agent, which anyone can copy. A signature proves the request is ours, and it works from any address, which matters because our probes run from several regions on infrastructure whose addresses change.

If your CDN verifies signatures, our checks identify themselves with no configuration from you at all.

If your CDN does not verify signatures, allow by User-Agent. Do not allow by IP address: our probes run from several regions and those addresses change as we add capacity, so an IP allowlist will break without warning.

Cloudflare

Under Security → WAF → Custom rules, create a rule with this expression and set the action to Skip (all remaining custom rules, plus managed rules and bot protection):

A plain Allow action is not always enough on its own, because Bot Fight Mode is evaluated separately. If checks are still turned away, confirm the rule is skipping bot protection too.

Nginx, Apache, or your own code

Exempt requests whose User-Agent contains Sentivel-Monitor from rate limiting and bot rules. If you rate limit by IP, our checks arrive on a schedule from a small number of addresses, so a strict per-IP limit can catch them.

AWS WAF, Akamai, Imperva, Sucuri

Add a string-match condition on the User-Agent header containing Sentivel-Monitor, and place that rule above your bot or reputation rules so it is evaluated first.

A block is not an outage, and we do not report it as one. When a WAF or CDN turns our check away at the edge, the request never reaches your service, so it tells us nothing about whether your service is healthy. Treating that as downtime would page your on-call, publish an incident on your status page, and damage your uptime figure, all for a service that never stopped working.

So when we detect that a check was blocked:

• No incident is opened and nobody is paged.
• The check is not recorded, so your uptime percentage is untouched.
• Your workspace owners and admins are emailed once, naming the service doing the blocking and what to change.

Checks resume on their own once we are allowed through. There is nothing to switch back on.

We only do this when a response positively identifies itself as an edge block, such as a Cloudflare challenge. An ordinary 403 from your application is a real failure and is still reported as one.

Synthetic traffic can distort your own numbers. Filter on the same Sentivel-Monitor token to exclude our checks from analytics and access logs.

If you would rather we hit a dedicated endpoint, point the monitor at one. A small health route is usually a better check than a full page: it is cheaper for you to serve and it fails for clearer reasons.

Email support@sentivel.com with the monitor URL and we will tell you exactly what we saw, including the response headers, so you can match it to a rule.