# Diagnosing deny-list changes that do not take effect
## Symptom
You removed an IP from the deny list in the dashboard, but requests
from it are still blocked. Or you added one and it is still getting
through from some instances.
## Cause
The SDK caches denied values client side for one minute. A denied
value is rejected without even calling Redis. So:
- Additions take effect immediately on the next limit() call.
- Removals take up to 60 seconds to propagate to every running
instance, because each instance holds its own cache.
## Confirm
Check the clock. If the removal is less than a minute old, wait. If
it is older than a minute everywhere, the value may be blocked by a
different list (auto IP deny list versus manual list) or the limit()
call is not passing the ip field at all, so the check never sees it.
## The matching trap
Deny lists do exact matching only. "CONTAINER_IP/24" will not block
"CONTAINER_IP", and a user-agent string must match character for
character. If an addition seems to do nothing, check for an exact
match first.
## Fix and verify
Wait out the minute, then re-test from the affected IP. For
operational runbooks, note the 60-second propagation delay next to
the dashboard link so the next on-call engineer does not page over
it.