Skip to content
Fixter Docs
↑↓ Select⏎ OpenEsc Close

Allow tests through your firewall

If a test you set up has been Rate limited, keeps failing with a 403, or gets a challenge page instead of your response, the CDN, WAF or rate limiter in front of your service is probably treating Fixter’s requests as unwanted traffic. This page helps you confirm that first, then lets the tests through.

Confirm that a firewall is the cause

Section titled “Confirm that a firewall is the cause”

Open the failed run on the test’s page (the API Tests page) or ask your agent for the test’s recent runs with get_api_test_runs. One of these three patterns means the block is in front of your service, not in it:

  • The run is Rate limited. The cause reads Rate limited by the target: the response was HTTP 429. If your service itself never answers 429, the limiter in front of it did.
  • The run failed its status assertion with a 403, for example Expected 2xx, got 403, and the recorded response body is not your service’s own error. An MCP test shows it as MCP server did not identify itself on its first run, or as MCP server rejected <method> once past the handshake.
  • The recorded response is a challenge page. The body in the run detail is HTML asking for a browser check, a captcha or JavaScript, which only bot protection sends. Bodies are cut at 16 KB, which is enough to recognise one.

Then prove it from outside Fixter. Paste this into a shell, replacing YOUR_ENDPOINT_URL with the URL your test calls, and it sends the same request twice, once with the User-Agent Fixter’s tests use and once without:

URL=YOUR_ENDPOINT_URL
curl -sS -o /dev/null -w 'with the User-Agent:    %{http_code}\n' -A 'FixterMonitoring/1.0 (+https://fixter.dev)' "$URL"
curl -sS -o /dev/null -w 'without the User-Agent: %{http_code}\n' "$URL"

A 403, 429 or 503 on the first and a 200 on the second is a rule that matches the User-Agent. The same code on both is a rule that matches something else (an IP range, missing cookies, a geography) or a limit your service has really hit; the vendor steps below cover both.

Your own CDN or WAF logs settle it fastest: filter them for the User-Agent FixterMonitoring and the action the rule took. If those logs already reach Fixter, ask your agent for log lines carrying that User-Agent, or open the failed run and use Open in Logs, which searches on the run’s trace id (how that works is on Debugging).

What to allow

Section titled “What to allow”
Allow byValueApplies to
User‑AgentFixterMonitoring/1.0 (+https://fixter.dev)Every request an HTTP test or an MCP test sends, and every OAuth2 token fetch a credential makes
IP address34.247.142.193All of them: one static IPv4 address in eu-west-1

Allow by User-Agent where your firewall can match a header. A User-Agent rule admits only the tests. An IP address rule admits every request that leaves Fixter’s infrastructure, because the address is shared by all of it, so use the IP only where the firewall cannot match a header (Cloudflare’s free plan is the common case).

Two details that decide which rule works:

  • A header the test or its credential sets wins over the fixed User-Agent: an HTTP test that sets its own User-Agent request header sends that value instead, and a User-Agent rule does not match it. Remove the header or allow by IP address.
  • The IP address changes only if the infrastructure behind it is rebuilt, and a change of address is announced ahead of time on this page.

Allow the tests

Section titled “Allow the tests”

Pick the variant that matches your firewall. Menu names are the vendor’s, as their documentation gives them.

Bot Fight Mode, the Free plan’s bot protection, cannot be skipped with a WAF custom rule: “You cannot bypass or skip Bot Fight Mode using WAF custom rules or Page Rules”, but “it will not trigger if an IP Access rule matches the request first” (Cloudflare: Bot Fight Mode). So allow the IP address with an IP Access rule (Cloudflare: Create an IP access rule):

  1. Open the Security rules page for your zone.
  2. Choose Create rule > IP access rules.
  3. Enter 34.247.142.193, choose the action Allow and the Zone scope.
  4. Select Create.

Allow “Excludes visitors from all security checks, including Browser Integrity Check, Under Attack mode, and the WAF” (Cloudflare: IP access rule actions).

Cloudflare shows the IP access rules option only once at least one IP access rule exists. If it is not there, create the rule with Cloudflare’s API (“Create an IP Access Rule”), as the same page describes.

Once the rule is in, the next run passes within one interval, or after the Retry-After you sent when that is later, and the two curl requests above return the same status. One passing run returns a rate-limited or failing test to Up.

What a 429 means for a test

Section titled “What a 429 means for a test”

When your side answers HTTP 429:

  • The run is Rate limited, not failed. Its status and cause are RATE_LIMITED, and the app shows the cause as Rate limited by the target. For an MCP test, a 429 on any request of the session counts.
  • It is not retried, whatever the test’s retry setting.
  • Retry-After is honoured. If your response carries it, the next run is deferred by it, up to one hour, when that is later than the next normal run. The run message then reads Rate limited by the target (HTTP 429); next check deferred by <N> seconds (or minutes); with nothing deferred it reads Rate limited by the target (HTTP 429).
  • The test turns Rate limited after the failure threshold. After as many rate-limited runs in a row as the test’s failure threshold, the test’s state turns Rate limited and it sends one notification, <name> is being rate limited. The next success returns it to Up and sends No longer rate limited: <name>. See Notifications.
  • Uptime is unaffected. Rate-limited runs are left out of uptime and never make a downtime interval.
  • A 429 during the trial run on save means the test is not saved. The app shows Trial run was rate limited by the target. Allow the tests first, then save again.

If an HTTP test’s status pattern accepts 429 (for example 429 or 4xx), a 429 is an ordinary response checked against the assertions, and none of the above applies. The full rules are in Retries and Retry-After and How states change.

If it is still blocked

Section titled “If it is still blocked”

A 403 or a challenge page is usually bot protection, not rate limiting, and the same allowlist fixes it. The test does not show it as Rate limited:

  • An HTTP test fails its status assertion, for example Expected 2xx, got 403. The run is a FAILURE: it is retried, counts toward the test going down and counts against uptime.
  • An MCP test that has not yet found its server’s revision (a Newest supported test on its first run, including the trial run on save) ends the revision lookup as none on a 401, 403 or 5xx. It fails assertion mcp.initialize, MCP server did not identify itself, with the run message the target did not identify itself as an MCP server.
  • An MCP test that gets past the handshake and then meets a bare non-2xx fails as CONNECT with MCP server rejected <method>, for example MCP server rejected tools/list.

Open the failed run to see the response your firewall sent; the run detail is described on Runs, states and uptime. If the test went down, the message it sent is on Notifications. If the test sets its own User-Agent request header, a User-Agent rule does not match it; remove the header or allow by IP address.

Still stuck? Email info@fixter.dev and one of our founders will help you fix your problem asap.