# Catch Heroku settings that drifted between staging and production

> Every Monday, we compare the settings on your Heroku staging and production apps and post what drifted apart to Slack before it breaks your next release.

- Workflow type: agent
- Services: Heroku, Slack Bot, Linear
- Categories: Engineering, Operations
- Published: 2026-08-14

## What it does

- Checks every Heroku pipeline each week and lines up each staging app against its production counterpart.
- Flags settings missing on one side, plus values pointed at the wrong environment, like a test-mode payment key sitting in production.
- Posts a short per-pipeline summary to Slack, and opens a Linear issue when a difference is likely to break your next release.
- Never writes secret values into Slack or Linear. It compares names and describes what a value looks like, so nothing sensitive leaks into a channel.

## What you'll need

- A Heroku account with access to the pipelines you want audited.
- At least one pipeline that has both a staging app and a production app, since the check compares the two against each other.
- A Slack workspace and a channel where the weekly report should land.
- A Linear account and a team to file issues into when something looks likely to break a release.

## Prompt

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.

## How to customize

- Change the timing. Monday at 8am suits a weekly release rhythm, but you can run it daily, or the morning before a scheduled release.
- Choose which channel gets the report, and route different pipelines to different channels when separate teams own them.
- Tune what counts as a real problem. You can tell it to ignore settings that are always meant to differ, or to treat certain names as must-match.

## FAQ

### Will this show my secret values in Slack?

No. The workflow reads your settings so it can compare them, but the Slack message and the Linear issue only ever contain setting names and a short description of what a value looks like. It will say a payment key looks like a test-mode key in production rather than showing any part of the key itself.

### Won't it flag everything, since staging and production are supposed to be different?

That is exactly the problem it is built to avoid. Plenty of settings should differ, like database locations, storage buckets, and vendor logins. This focuses on names that exist on one side but not the other, and values that look like they belong to a different environment than the app they are set on, so you get a short list worth reading instead of a wall of noise.

### What if I have more than one pipeline?

It walks all of them. You get one summary per pipeline, so a team that owns several apps can scan each one separately instead of untangling a single combined report.

### Does this change anything in my Heroku setup?

No. It only reads. Nothing is edited, promoted, or restarted, so it is safe to run against production.

### What happens if a pipeline has no staging app?

There is nothing to compare, so it notes the pipeline as skipped and moves on rather than reporting a problem that is not real.

Use this prompt in General Input: https://www.generalinput.com/prompts/catch-heroku-settings-that-drifted-between-staging-and-production