mildnode
Sign inGet started

Allowlisting the Mildnode monitor

If you found this page from a user-agent string in your access logs: the traffic is a synthetic monitor, run on behalf of the owner of the site it is visiting, to check that a specific user journey still works. It is not a crawler, it does not scrape, and it does not submit payments.

How to identify us

We identify ourselves on every request we make. These values are stable and we will not change them without bumping the version in the user-agent.

  • User-Agent: Mozilla/5.0 (compatible; MildnodeMonitor/1.0; +https://mildnode.com/monitoring/allowlist)
  • Request header: X-Synthetic-Monitor: mildnode
  • Current monitor version: 1.0

The header is the most reliable thing to match on for requests that reach your own servers, which is what any log or analytics filter sees. User-agent strings get rewritten by proxies; the header does not.

We send the header to your domain only, never to third parties your pages load from. A custom header turns a cross-origin request into a preflighted one, and a CDN that does not expect ours would refuse it - which would stop scripts on your own page from loading. Everything we request, from anyone, still carries the user-agent above.

Keeping us out of your analytics

A synthetic checkout journey running every few minutes will otherwise show up in your funnel and conversion numbers. Filter on the X-Synthetic-Monitor header at your edge or CDN, or exclude the MildnodeMonitor user-agent in your analytics tool. In Google Analytics 4 this is Admin → Data Streams → Configure tag settings → Define internal traffic; Plausible and Fathom exclude known bot user-agents automatically.

Allowlisting by provider

If your bot protection challenges or blocks us, the journey cannot tell its owner anything useful. We report this as “blocked” rather than as an outage, but it still means the monitoring is not working.

  • Cloudflare — add a WAF custom rule with the expression http.request.headers["x-synthetic-monitor"][0] == "mildnode" and the action Skip (skip all remaining custom rules, Bot Fight Mode, and rate limiting). Bot Fight Mode cannot be bypassed per rule on the free plan; Super Bot Fight Mode can.
  • DataDome — add a custom rule matching the X-Synthetic-Monitor header with the response Allow.
  • AWS WAF — add a rule above your bot-control rule group matching the header, with the action Allow.
  • Imperva / Incapsula — add a security exception on the bot-protection policy for the header.
  • Akamai — add a Bot Manager exception for the header, or classify the user-agent as a known good bot.
  • HUMAN (PerimeterX) — add the header to the allowlist in the enforcer configuration.

Allowlisting by IP is not practical: we run on Cloudflare’s network and our egress addresses are not stable. Match on the header.

How much traffic this is

A journey runs on a fixed interval, at most once a minute, and is a single browser session visiting a handful of pages. We cap dispatches at 2 per domain per minute regardless of how many journeys are configured against it, and we offset each journey’s schedule so they do not all fire on the same second.

Checkout journeys are observation-only: we fill the cart, confirm the payment form mounted and that the total adds up, then empty the cart again. We never submit a payment.

Making it stop

If this traffic is unwelcome, email contact@mildnode.com with the domain and we will disable monitoring for it. That mailbox is read by a person, not a bot, and we will act on it whether or not the request comes from the account that configured the journey.

We also require every customer to prove control of a domain via a DNS TXT record before any journey against it may run, so monitoring cannot be pointed at a site its owner does not control.

Contact

Abuse and opt-out: contact@mildnode.com. Anything else: contact@mildnode.com.