Tuning without dials: which lever to reach for first

The expectation comes from a familiar model, and the model has a defect.

A strictness setting promises one decision instead of many. Its cost is that nobody can say what a position on it means: moving from one level to the next changes a large number of individual decisions at once, in ways that differ per site, so the effect cannot be attributed to anything. When something breaks afterwards, the available explanation is that the level is now higher, which is not an explanation.

The absence of a scale forces the opposite habit. Every change names a rule, a route, a request, or a limit, and every change can therefore be tested, reversed, and explained to somebody who was not there. That is slower on the day and much faster over a year.

Everything you can adjust is one of these.

Which rules apply, and where. The scope of a rule is a decision: a rule that belongs on a form does not necessarily belong on a static URL path, and narrowing where it applies is a change with an obvious meaning.

Which requests are exempted. The narrow carve-outs for the cases where your own content or a known integration collides with a rule. These are covered by exceptions, including the part that matters most, which is that each one carries a date.

Where limits are set. Rate limiting is applied to the domain, and what that means in practice, along with how to choose a limit at all, belongs to rate limiting.

Four rungs, and the first is the one people skip because it is not a filtering change at all.

Change your own thing. Where a rule collides with your content, the first question, before any configuration, is whether your side is doing something it does not need to do: a form accepting raw HTML it never displays, an integration sending unsigned HTTP requests it could sign, a route accepting a method it does not use. Fixing that removes the collision permanently and improves the site independently of any filtering.

Narrow where the rule applies. If the collision is real and your side is correct, restrict the rule to the URL paths where it earns its place. This keeps the protection and removes the mismatch, and it stays true when the site grows.

Write an exception. Narrow, owned, dated. Correct when the collision is specific and legitimate, and the right answer for integrations and callbacks that will not change for you.

Change something broadly. Last, deliberately, and rarely. A broad change is the only one whose effect you cannot fully predict, so it belongs at the end of the list rather than at the start, where it usually appears because it is the quickest thing to do at the moment somebody is complaining.

Three habits, and they are the same ones that make a rollout survivable.

One change at a time, stated in a sentence. Two changes made together produce an outcome that belongs to neither.

Watched for a cycle of the route it affects, not for a fixed period, since a route used on weekdays and an integration that runs nightly reveal themselves on different schedules. That reasoning is set out under staged rollout.

Recorded with its date and its reason. The report that tests your change arrives days after you make it, and the only question it raises is what was different that day.

Two things, and both are common.

A single event. One probe, one scanner, one odd request from an address that never returns is not a signal. Tuning in response to it optimises your configuration for something that already stopped, and every such change is permanent until somebody removes it.

The count of entries. Tuning until the record is quiet is tuning toward a log that tells you nothing. Entries are the instrument, not the fault; a configuration producing no entries is either seeing no hostile traffic, which is unlikely, or has been adjusted until it stopped reporting. The second is indistinguishable from the first at the moment you achieve it and very distinguishable later.

Tuning is not a setup step, because the fit degrades from your side rather than theirs.

Come back to it when the site changes in a way that changes traffic: a new form, a new integration, a market that brings visitors from somewhere your rules have never seen, an application rewritten to send different requests. In each case the configuration did not change and stopped fitting anyway.

The cheap version of this is a short observation after each such change, on the affected routes only, rather than a periodic review of everything. The expensive version is discovering the mismatch through a customer months later.