Catch Heroku settings that drifted between staging and production

Every Monday at 8am, audit configuration drift across the stages of my Heroku pipelines and report what you find in Slack.

Start with Heroku List Pipelines to enumerate every pipeline the account can access. For each pipeline, call List Pipeline Couplings to get the apps coupled to it and the stage each one sits in. Work only with the staging and production stages, and ignore review and development apps. If a pipeline has no staging app or no production app there is nothing to compare, so note it as skipped and move on rather than reporting a false problem.

For every staging and production app you identified, call Get Config Vars. Then compare each staging app against its production counterpart within the same pipeline, key by key.

Report three categories of finding. First, keys present in staging but missing in production, which is the classic promotion breaker because a build promoted out of staging expects a setting production does not have. Second, keys present in production but missing in staging, which means staging is not a faithful rehearsal of production. Third, keys whose values look pointed at the wrong environment: a test-mode payment key sitting in production, a staging bucket name or staging hostname referenced from a production app, or a localhost or tunnel URL anywhere at all.

Use judgement about what actually matters. Many keys are supposed to differ between staging and production: database URLs, storage buckets, per-environment hostnames, and separate vendor credentials for the same vendor should all hold different values, and flagging those is noise rather than drift. What matters is a key that exists on one side and not the other, or a value whose shape says it belongs to a different environment than the app it is set on. Rank findings by whether they would genuinely break or corrupt the next promotion, and say plainly which ones would.

Config vars hold live secrets, and this rule is hard and must not be softened: never print a config var value into Slack or Linear. Compare key names and redacted value shapes only. Describe a finding as "STRIPE_SECRET_KEY looks like a test-mode key in production" rather than quoting the value or any fragment of it. When you need to characterize a value, say what it resembles, such as a test-mode prefix, a staging hostname, or a localhost URL, without reproducing the value. Never echo a full set of config vars into any output.

Post one summary per pipeline to Slack using Send a Message. Lead with the pipeline name and whether it is clean or has drift, then list the findings grouped by the three categories, naming the app and the affected key names in each. If a pipeline is clean, say so in a single line instead of padding it out. Keep the whole message scannable for someone reading it first thing on a Monday.

When a missing key or a wrong-environment value could break the next promotion, open a Linear issue with Create Issue. Name the pipeline, the app, and the affected key names in the title and description, and explain what would go wrong the next time someone promotes. Apply the same redaction rule inside the issue: key names and value characterizations only, never values. Routine differences that carry no promotion risk belong in the Slack summary only and should not become issues.