> ## Documentation Index
> Fetch the complete documentation index at: https://www.datum.net/docs/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Agent home for Datum, with what it is, pricing, and how to act: https://agents.datum.net
> If you can only fetch URLs: read https://www.datum.net/docs/llms.txt in full and open the most specific page for the task. Commands, limits, and field paths are on task, operations, and limits pages, not on section overviews. Pages described as "Documentation is coming soon" are placeholders.
> If you have a shell or can save files: download https://www.datum.net/docs/llms-full.txt (every page, about 740 KB) once and search it with grep, instead of fetching pages one at a time.
> datumctl describes itself: `datumctl api-resources` lists resource types and `datumctl explain <resource>` shows a schema. To act on live resources, use Datum MCP or datumctl. To search the docs, use the Docs MCP server at https://www.datum.net/docs/mcp.

# Roll out traffic protection safely

> Turn on the Datum web application firewall with datumctl without blocking real users, using Observe mode and access logs to tune it first.

Every load balancer created with `datumctl alb create` gets traffic protection in **Enforce** mode at sensitivity 1. That is a sensible default for something new. It is not a sensible thing to switch on in front of a live site without looking first.

This guide covers doing it in the order that does not block your own users.

## Where it stands

```bash theme={null}
datumctl alb waf describe my-app
```

Three states:

| Mode | What happens |
| - | - |
| `Observe` | Requests are inspected and logged. Nothing is blocked. |
| `Enforce` | Matching requests are blocked. |
| `Disabled` | The policy exists but does nothing. |

Sensitivity — the paranoia level — runs 1 to 4. Higher catches more and produces more false positives.

> [!NOTE]
>
> The cloud portal offers sensitivity 1 and 2 only. Setting 3 or 4 here works, but the portal will not be able to change it afterwards.

## Putting an existing site behind it

Do not go straight to `Enforce` on a site that already has users.

**1. Start in Observe**

```bash theme={null}
datumctl alb waf set my-app --mode Observe --paranoia 1
```

Requests are inspected and logged, and nothing is blocked.

**2. Let it see real traffic**

Long enough to include whatever runs weekly — reports, exports, batch jobs, a partner's nightly integration. A weekday is rarely enough.

**3. Switch to Enforce**

```bash theme={null}
datumctl alb waf set my-app --mode Enforce --paranoia 1
```

**4. Check what is being blocked**

```bash theme={null}
datumctl alb logs my-app --since 1h --code 403
```

Look for legitimate traffic in there: file uploads, rich text or Markdown in request bodies, SQL-like strings typed into a search box, long base64 values, API clients sending unusual headers. All of these trip rules at higher sensitivities. If you find any, see [When real traffic is being blocked](#when-real-traffic-is-being-blocked).

**5. Raise sensitivity one level at a time**

Repeat the same check at each level. Do not jump from 1 to 4.

## When real traffic is being blocked

The signature is requests reaching the load balancer and coming back `403` without ever reaching your origin. Your origin's own logs show nothing at all, which is what makes it confusing — from the origin's side the traffic simply vanished.

```bash theme={null}
datumctl alb logs my-app --since 1h --code 403 -o wide
```

The fix is almost never to turn protection off. In order of preference: drop to `Observe` while you investigate, lower the sensitivity, or narrow what runs.

```bash theme={null}
datumctl alb waf set my-app --mode Observe
```

Turning it off entirely is a decision to make knowingly:

```bash theme={null}
datumctl alb waf disable my-app
```

> [!WARNING]
>
> `waf disable` deletes the policy without asking for confirmation.

## A load balancer with no protection at all

This is worth checking for, because nothing reports it as a problem.

Creating a load balancer in the cloud portal attaches protection on a best-effort basis. If that attach fails, the load balancer is created anyway, you are not told, and the security card simply reads as disabled. The same is true of `datumctl alb create`: if the load balancer is created and the policy then fails, the command exits non-zero having left an unprotected load balancer behind.

So after any failed create:

```bash theme={null}
datumctl alb waf describe my-app
```

If it reports off, attach one:

```bash theme={null}
datumctl alb waf set my-app --mode Enforce --paranoia 1
```

## Rule exclusions and rate limiting

`datumctl alb waf` covers mode and sensitivity. Excluding specific rules, setting score thresholds, rate limiting and circuit breaking are manifests — see [WAF configuration](https://www.datum.net/docs/alb/configuration/waf.md) and [HTTPProxy and WAF capabilities](https://www.datum.net/docs/alb/httpproxy/overview).

Keep the detection level at or above the blocking level so you can preview stricter rules in the logs before enforcing them.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.