Alert configuration should control business behavior, not system structure

Configuration should let the business choose among behaviors the system already knows how to execute safely. It shouldn’t invent new system behavior at runtime.

A threshold, schedule, route, message, response option, or active variant expresses business judgment. The alert lifecycle, state machine, payload contract, retry policy, idempotency rules, and writer implementation define whether the system remains correct when that judgment changes. The first group belongs in a reviewed control surface. The second belongs in code.

Configuration shortens the business feedback loop

Operational rules rarely survive first contact unchanged. A threshold creates too much work. Friday delivery is useless. One segment needs different wording. A response should request a note. A team can absorb five new alerts per day, while another can handle twenty.

These are normal corrections. Requiring a deployment for each one makes the alert system expensive to improve, so weak rules linger longer than they should.

A useful configuration surface covers decisions such as:

• which cycles and variants are active
• scope values and thresholds
• allowed weekdays, blackout windows, cooldowns, and expiry windows
• routes, fallback owners, grouping, and workload limits
• message templates, labels, and approved placeholders
• response options and the known action attached to each response

The configuration doesn’t own the implementation of those actions. It selects from a bounded vocabulary. A response may request close_alert, create_follow_up, or set_account_status. Code defines what those operations mean, validates their inputs, performs them, and records the result.

That distinction keeps routine tuning cheap without turning a table into an untyped programming language.

System guarantees stay in code

The machinery that preserves correctness under failure should change for engineering reasons, not business reasons.

Candidate claiming, state transitions, retry classification, dead-letter behavior, payload validation, deduplication semantics, writer mappings, audit records, and response correlation need tests and explicit interfaces. They also need one searchable implementation when an incident crosses several services.

Moving these concerns into configuration removes the safeguards that made them understandable. The complexity still exists. It now lives in rows, implicit ordering, weak references, and runtime interpretation. That’s a worse codebase with fewer tools.

Configuration may supply parameters around structural behavior. It can set a maximum attempt count or choose a seven-day repeat window. Code still decides how attempts interact with execution claims, which failures are retryable, whether a delivered alert starts the repeat window, and what happens when a reminder is already pending.

Ask whether a value selects supported behavior or defines new behavior. Selection can live in configuration. Definition belongs in code.

Treat configuration as a production interface

Use narrow, typed records instead of one generic JSON field. Give each table or object one job: variants, schedules, templates, response options, route limits, or approved actions. Validate references before activation. An unknown answer key, unsupported placeholder, invalid route, missing entity reference, or disallowed action should fail before a recipient sees anything.

The effective configuration must also be inspectable. Operators need to see which values are active after defaults and overrides are applied, which variant owns them, who changed them, and which alerts were produced under that version. A database row that can change production behavior needs history. Otherwise, editing it is an unaudited deployment.

Changes should have a review path proportional to their blast radius. Editing message copy is different from enabling writeback for a response. Business owners can usually manage wording, schedules, thresholds, and limits. A smaller group should approve operations that mutate business state. The writer’s supported operation set should remain narrower still.

A preview should show representative candidates, rendered messages, expected routes, and projected volume before activation. The cheapest alert to repair is the one that hasn’t interrupted anyone yet.

Resist the generic rule engine

The pressure to make every condition configurable often produces a miniature expression language: arbitrary fields, nested operators, joins, formulas, and dynamic side effects. At that point the system has built another application platform, except its behavior is harder to type-check, test, refactor, and review.

Start with named alert families implemented in reviewed models. Move stable values into configuration when the shape of the rule is understood and business owners genuinely need to tune them. Add supported operators only when several real rules share the same requirement.

Duplication across two configuration records is cheaper than a generic rule engine nobody can safely change.

Apply the boundary

Business configuration should answer questions such as when should this rule run, who should receive it, how much work may it create, what should the recipient see, and which approved response may they choose?

Code should answer how does work move, what makes an operation valid, how do retries and duplicates behave, what state transitions are legal, and what evidence is written before success is returned?

That boundary can move as the system matures. A hardcoded threshold may earn configuration after repeated tuning. A supposedly configurable action may need to return to code after its edge cases become structural. The rule isn’t ideological.

Use configuration when it makes business judgment easier to change without weakening the guarantees around it.