Skip to content

CONCEPT Cited by 1 source

Warn mode vs enforce mode

Warn mode vs enforce mode is the two-state operational lifecycle for any threshold-based control (resource budget, rate limit, throttler, rule engine, policy gate) where the operator cannot know the right threshold in advance and must learn it from real traffic before committing to actually blocking anything.

The two states

  • Warn mode — the control evaluates every request against the threshold and records over-budget events, but does not block or reject. The request completes normally; the telemetry records a flag. Operators read the flag-count over time to answer "is this threshold set too tight, too loose, or about right?"
  • Enforce mode — the control evaluates every request against the threshold and actually blocks / rejects over-budget requests. Callers must retry. The telemetry continues to record flag-count, now reflecting actual rejections.

The flip from warn to enforce is a deliberate operator decision after the threshold has been tuned to a value where flag-counts match the operator's intent (low false positives under normal load, high flag-counts under unusual load).

Why you can't skip warn mode

Threshold-picking is a distribution-learning problem. You do not know — at configuration time — what fraction of your traffic will exceed any given threshold. You can guess, and guesses are wrong often enough that straight-to-enforce deploys produce immediate customer-visible impact (blocked critical traffic, retry storms, cascading failure).

Ben Dicken's canonical framing (Source: sources/2026-04-21-planetscale-graceful-degradation-in-postgres):

"There's no need to get the tunings above perfect from day one. You can start every budget in warn mode. This will not kill any queries that exceed the budget. Rather, it will warn, and you can click into the budget to see how many queries are exceeding it over time."

The observed-violations time series tells the operator where the threshold actually sits relative to the workload's distribution — information that's not available a priori.

Canonical lifecycle

The four-stage lifecycle Dicken names:

  1. Comment — tag queries with metadata (SQLCommenter or equivalent).
  2. Warn — attach budgets to tag values. Start permissive. Observe over-budget counts.
  3. Monitor — watch the counts over a meaningful window (days, not hours, so that traffic-pattern variation is captured). Adjust thresholds up or down.
  4. Enforce — flip to enforce once the count profile matches intent. Optionally flip back to warn ad-hoc for re-tuning.

Where this pattern shows up

Same shape at different altitudes:

  • Traffic Control budgets — Dicken canonical instance.
  • Logging-mode-to-enforcement rollout — Meta's policy zones; operator observes policy violations in logging mode before flipping to enforcement that would actually block data-flow violations.
  • Throttler fail-open vs fail-closed — the related but distinct axis: what does the throttler do when it cannot collect its own metric? Warn/enforce is the parallel question: what does the throttler do when it can collect its metric and the metric is over?
  • Cloudflare WAF managed rulesets — shipped with log action first, switched to block after real-traffic false-positive analysis.
  • IDS / IPS — log-and-alert first, then move to prevent after tuning.

What the "warn" telemetry needs

For warn-mode to be useful, the over-budget telemetry must be queryable (not just a count; ideally broken down by tag, time-window, client identity). The Dicken example shows a 3-hour window with "thousands" of over-budget events surfaced in Insights — that granularity is load-bearing, because "how many" without "which" doesn't tell the operator whether the flags are one misbehaving call-site or a systemic under-sizing.

In-band warning channel

An additional PlanetScale-specific mechanism: even in enforce mode, warnings surface as [PGINSIGHTS] Traffic Control: messages returned in the query response alongside row data, so the application can observe budget pressure "from within your application without any user-facing effects" (Source: sources/2026-04-21-planetscale-graceful-degradation-in-postgres). Effectively: warn-mode observability continues to work alongside enforce-mode blocking, via a diagnostic channel delivered inside the Postgres wire protocol.

Seen in

Last updated · 347 distilled / 1,201 read