> ## Documentation Index
> Fetch the complete documentation index at: https://docs.hiveku.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Allow a Monitor Through the Firewall
> See what Hiveku's edge firewall challenged or blocked on your site, and allow your own monitor or audit tool through
Every Hiveku-hosted site sits behind Hiveku's edge firewall. Bulk scrapers are blocked and unknown automated clients are asked to prove they are a browser; real visitors, search engines, AI assistants, link previews and common uptime monitors pass without noticing it. The **Firewall** section on the Hosting page shows what the firewall did for your site and lets you allow a specific client -- an uptime monitor, an agency's audit tool -- without turning protection off.
```
Project > Hosting > Firewall
```
The section opens with its status line: "Hiveku's edge firewall protects this site. Bulk scrapers are blocked and unknown automated clients are asked to prove they are a browser. Real visitors, search engines, AI assistants, link previews and common uptime monitors pass."
## What the counters mean
Three counters cover the last 7 days, with the coverage date under them ("through 2026-09-17, updated daily"). The numbers are rolled up once a day from the edge access logs, so today's traffic shows up tomorrow.
| Counter | What it counts |
| ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Challenged** | Requests from an automated client that was asked to prove it is a browser. A browser passes the check without anyone noticing; a script or monitor that cannot run JavaScript receives an HTTP `202` with an empty body instead of the page. |
| **Blocked** | Requests answered with a `403`: the firewall refusing a bulk-crawler cloud network known for scraping. A `403` your own site returns is counted here too, because the count is read from the response status. |
| **Rate limited** | Requests answered with a `429` because one address sent more than the firewall allows in five minutes. |
When nothing was challenged, blocked or rate limited, the section reads "Nothing has been challenged in the last 7 days."
## The clients table
**Automated clients that were challenged or blocked** lists the top 20 clients by request count over the same 7 days:
| Column | What it shows |
| ------------- | ---------------------------------------------------------------------- |
| **Client** | The user agent the client sent, truncated; hover to read the full text |
| **Network** | The network number (ASN) and the country the requests came from |
| **Requests** | How many requests in the 7-day window |
| **Last seen** | When the client was last seen |
| **Outcome** | Challenged, Blocked or Rate limited |
| **Allow** | On challenged rows only: let this client through the browser check |
Below the table, **Allowed for this site** lists every allowance in place: its kind (user agent or address), the value, your note, who added it and when, with a **Remove** action on each row.
## How to allow a client
From your project, click **Hosting** in the sidebar and scroll to **Firewall**.
Look for your monitor or audit tool in the clients table. The **Client** column shows the user agent it sends; hover to read the whole string.
A small confirmation opens with the proposed exception: the client's own user-agent token when it has a distinctive one (for example `MyMonitor/2.1`), or its address when the user agent is generic.
Add a note if you want to remember why (for example "Uptime check for the marketing team") and confirm. The allowance is saved immediately and pushed to the edge; if the edge cannot be updated at that moment, it is picked up within the day.
The **Allow** button works from a row in the table. A client that has not appeared yet shows up after the next daily rollup, so let it make a few requests first.
## What an allowance does and does not do
Allowing a client skips the browser check only. Volume limits and the blocks on known scraper networks still apply. An allowed user agent works on this site's addresses only; an allowed IP address is trusted wherever it goes on Hiveku hosting.
* A **user-agent allowance** matches any request to this site whose user agent contains the token, case-insensitively. It works on this site's addresses only, because a user agent can be copied by anyone. A token that would exempt browsers or verified bots (for example `Mozilla`, `Chrome`, `Googlebot`, `bot` or `http`) is refused; use the product's own token instead. `bot` is refused even inside a product name, so a client with such a name is allowed by address.
* An **address allowance** matches one IPv4 or IPv6 address or a small range. It is trusted across Hiveku hosting, because an address identifies one machine. Private, loopback and multicast ranges are refused.
* Each site can hold up to **10 active allowances**. Remove one you no longer need before adding another.
* An allowance never lifts the per-address rate limit or the block on known scraper networks, so a monitor that hammers the site is still rate limited.
## Removing an allowance
Under **Allowed for this site**, click **Remove** on the row. The change is pushed to the edge right away and, at the latest, by the next daily sync; from then on that client is challenged like any other.
## Troubleshooting
If the monitor reports an HTTP `202` with an empty body, or a response carrying the header `x-amzn-waf-action: challenge`, that is the firewall's challenge, not your site; visitors are seeing the page. Either have the monitor send a recognisable user agent -- its product name and version -- or find it in the clients table and click **Allow**. A `HEAD` request is never challenged, so a monitor that only needs the status code can use one.
A token that appears in every browser's user agent, or in a verified search-engine bot's, would exempt all of them, so it is refused. Use the distinctive part of your tool's user agent instead, such as `MyMonitor/2.1`, or allow the client by address.
Either nothing automated was challenged, blocked or rate limited in the last 7 days, or the daily rollup has not run yet for a site that was just deployed. The coverage date under the counters says which day the numbers run through.
An allowance reaches the edge within the day. If the client is still challenged after that, hover the **Client** column and check that the token you allowed really appears in the user agent it sends, and check its **Outcome**: an allowance does not change a Blocked or Rate limited row.
## What's Next?
Cookie consent, security headers, PWA, SEO
Debug production issues with log streaming