Because a new blocking rule that is tuned wrong will block real users: a rate limit set too tight, a scanner filter that also matches a legitimate crawler, a velocity rule that trips on a busy real customer. Ship it straight to enforce and you risk a self-inflicted outage that looks exactly like an attack. This is the practical form of a simple principle: if you put a rule in place, you need to know what it will catch and what it will release, before it is live.
Run every new blocking, velocity or rate rule in observe-only mode first. It is testing the smoke alarm before you wire it to the sprinklers:
# Stage 1 (observe): log what it WOULD catch, do NOT block
if rule_matches(request): log_candidate(request)
# ...review the candidate list. Any real users / good crawlers in there? Re-tune.
# Stage 2 (enforce): now act
if rule_matches(request): block(request)
Review the candidate list with your own eyes, confirm no legitimate traffic is caught, and only THEN flip to enforce. Keep the observe path available even after enforcing, so you can drop back to observe instantly if something legitimate starts getting caught - that one-step rollback turns a potential outage into a five-minute non-event. Watch the first day of enforcement closely; that is exactly when a mis-tuned rule reveals itself by catching someone real.
The same look-before-you-trust-it discipline applies to your monitoring as a whole. Automation only catches what you told it to check, so run two tiers: a scheduled automated sweep that confirms your health and posture checks are green (are all monitors reporting? any red tiles? any check stale or a cert nearing expiry?), and a short daily human review that looks for what the automation missed - scanning the traffic that matched no rule at all, to spot the slow, quiet, low-volume probe that a threshold would never trip. The automated tier keeps the floor; the human tier finds tomorrow's rule. Write the daily review down as a short repeatable protocol so it is consistent and can be handed to another person or an AI assistant.
Related: rate limiting correctly and getting the real client IP (the rule you most want to observe first), and where monitoring sits overall: https://www.tigzig.com/agents-faq/what-should-i-monitor-for-a-small-production-app. Full item: https://www.tigzig.com/security/monitoring.
← All Agents FAQ