Our monitoring probe

It makes a single HTTP request to one URL, on a schedule the customer sets (5 minutes by default, never more often than once a minute). Nothing else.

• It only ever requests a URL somebody entered into their own Sentivel account. We do not discover endpoints and we never probe a host nobody asked us to.
• It does not crawl. No links are followed, no sitemap is read, no second page is fetched. Redirects are followed for the one URL being checked, and no further.
• It executes no JavaScript, stores no cookies, and reads at most 1 MB of the response before stopping.
• It does not submit forms, and it uses the HTTP method the customer configured, which is a read method unless they deliberately chose otherwise for their own endpoint.

Because every request is to a URL its own owner nominated, this is not crawling and robots.txt does not describe it. If you would rather we did not reach your service at all, see below.

Our checks send this User-Agent:

Match on Sentivel-Monitor rather than the whole string, so a version bump does not break your rule.

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, ticking all remaining custom rules, managed rules, and Super Bot Fight Mode:

Keep the expression to the User-Agent. Narrowing it further, to one path or to a header you expect us to send, gives the rule more ways to stop matching than to match.

If you added that rule and we are still blocked

Bot Fight Mode is almost always the reason. It runs outside the rules engine, so Skip, Bypass and Allow have no effect on it and no custom rule can exempt us from it.

Turn it off under Security → Bots. On Pro and above, Super Bot Fight Mode covers the same ground and does honour the rule above.

A challenge served this way carries a cf-mitigated response header. That is the signal we name in the email we send when your checks stop getting through.

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.

You are entitled to. Block requests whose User-Agent contains Sentivel-Monitor and we will stop reaching you; we do not retry from elsewhere, rotate identity, or attempt to look like a browser to get around it.

It is worth knowing what happens next, because the person being blocked is usually your own colleague: their monitor stops being able to see the service. We do not report a blocked check as an outage, and we email them to say their firewall is turning us away, so the block is visible rather than silent.

If our checks are reaching you and you do not believe any of your team asked for them, email security@sentivel.com with the URL and we will investigate and stop them.

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:

• We check the service a different way. A firewall works at the HTTP layer, so we confirm the host still accepts connections instead. That still catches an outage; what it can’t see is the response, so status codes and keyword checks pause until we’re allowed through.
• 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.