Aglet

Learn from recurring configuration drift after releases

Recurring drift makes code-only release reviews unreliable. Compare prior episodes for the same setting, inheritance path, stale process, or missing identity. Preserve a safe reference that lets future reviewers detect drift without increasing secret exposure.

Keep the lesson for the next incident

  1. Compare drift boundaries

    Align baseline, runtime source, load time, environment, service, and observed behavior across episodes. Identify the repeated divergence point and distinguish it from unrelated settings or releases.

  2. Improve safe identity

    Choose a redacted revision, digest, or classification that can accompany release evidence. State who records it, what it proves, and what conclusions still require behavioral comparison.

  3. Define reload recurrence

    Create a review rule for a runtime identity outside the baseline or a behavior change after a configuration boundary. Include stale worker and scheduled-job checks when they mattered previously.

What to carry forward

The lesson should add one safe configuration identity or reload check and a recurrence rule. Treat it as provisional until later releases show that all relevant runtimes can be compared without exposing secret material. Document which configuration identity and reload evidence future release reviews need, with a safe redaction rule and a check for drift between intended and served settings.

Keep the decision with the work.

Use a Work Item in Aglet to record the problem, the evidence you have, and the next decision. Add an owner and priority, then keep updates in the discussion so the next person can follow the reasoning.

Create an account See the product workflow