Audit the Config Before Launch

Assume the config will fail, then hunt for default values, secrets, and environment gaps

You are the SRE signing off the release, and your job is to find problems, not confirm that everything looks fine. Audit the config and environment variables below: 1) list every setting that only works because of a default, and write that default out; 2) flag anything where a mismatch across environments in secrets, connection strings, timeouts, retries, or concurrency limits would cause an incident; 3) trace the specific paths that work locally and fail in production; 4) give a pre-launch checklist sorted by risk, with a box for each item. Do not comment on formatting, and do not assume the platform catches it.

[config files / env var list / deployment environment]

How to use

Look hardest at the values that are not written down: default timeouts, default retry counts, and empty-string secrets are usually more dangerous than a wrong value.

Good for

A new service is about to take its first production traffic, and its config was assembled by copying staging.
You are moving a service to a new region and need to know which settings silently depend on the old environment.

Not for

You are flipping one documented feature flag with a known default: a full audit is overkill.
Config is injected from a platform template you cannot change: spend the time on application behavior instead.

Example

Input

DATABASE_URL=postgres://app@db:5432/app
REDIS_URL=redis://cache:6379
REQUEST_TIMEOUT=
RETRY=3
LOG_LEVEL=debug

What you get

`REQUEST_TIMEOUT` is empty, which most clients either reject at parse time or treat as no timeout at all — that is a launch-day outage, not a warning. In production, `LOG_LEVEL=debug` can write PII into logs, and `RETRY=3` on a non-idempotent write path multiplies duplicate orders. Sort the checklist as won't-start > data corruption > cost/noise, and give the expected value for each key in the target environment.

Common mistakes

Asking 'is there anything wrong with this config?' without naming the deployment environment: it cannot know whether `redis://cache` resolves in production.
Treating the checklist as a one-off: with no named owner and no gate, nobody actually ticks the boxes.

Try tweaking it like this

Add 'assume this is a payments service and every default must be written explicitly' and the review shifts from style to failure modes.
Ask for 'the user-visible symptom when each item is wrong' to separate fatal settings from ones that are merely painful to debug.