Skip to main content
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

Three states: Sensitivity — the paranoia level — runs 1 to 4. Higher catches more and produces more false positives.
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

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

Read what would have been blocked

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.
4

Switch to Enforce

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.
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.
Turning it off entirely is a decision to make knowingly:
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:
If it reports off, attach one:

​
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 and HTTPProxy and WAF capabilities. Keep the detection level at or above the blocking level so you can preview stricter rules in the logs before enforcing them.
Last modified on September 26, 2026