Post-Deploy Downstream Integration Triage Playbook

Right after a migration, deploy, or environment change, a downstream integration can go quiet without a visible error: a webhook stops firing, records stop being written, and every workflow keyed off them stalls. Or the service never comes up, crashing on startup from per-environment config that bled together on a shared slot. This playbook isolates scope first — what still works narrows the fault — then walks config, webhook wiring, and per-environment isolation, least to most invasive. The rule that catches the silent version: verify each downstream consumer sees the expected effect, not just that the webhook fires. [216]

Use this playbook when a downstream integration stops working immediately after a migration, deploy, or environment change — or when a service crashes on startup after one.

Typical triggers:

• A post-change webhook no longer fires, so tags or records stop being written and dependent workflows stall. [216]
• Some flows still work while one goes silent — the working ones localize the fault. [216]
• A service crashes on boot right after a config migration to a new environment. [2216]
• Pre-prod and production callbacks collide, or a shared slot mixes their settings. [2216]

Classify before you touch anything. A silent partial failure is easy to under-rate.

Name roles up front so escalation is not improvised under pressure.

• Cutover owner: runs this triage, owns the decision to roll back.
• Integration escalation: owns the webhook endpoints, signing secrets, and connection strings.
• Comms lead: owns messaging to downstream workflow owners whose flows stalled.

[ ] 1. Map what STILL works. If one flow (e.g. the calendar flow)
       runs while another is silent, the fault is that ONE
       connection, not the whole integration. [216]
[ ] 2. Read the config the service booted with. Confirm each value
       is a single value, not a concatenation of every app setting
       jammed together. [2216]
[ ] 3. Check the connection string / return URL points at THIS
       environment's resource, not another's. [2216]
[ ] 4. Confirm the webhook is still wired to fire after its trigger
       event, and that its signing secret matches the endpoint. [216][2216]
[ ] 5. Confirm per-environment settings are pinned as sticky. On a
       shared slot, unpinned settings bleed together and can down
       the app at boot. [2216]
[ ] 6. Follow one event end to end: webhook fires -> tags/records
       written -> downstream workflow resumes. Do NOT stop at "it
       fired." [216]

Match the symptom to the cause. Each branch points to one mitigation.

Apply the least invasive fix that resolves the diagnosed branch. Do not stack fixes you have not diagnosed.

1. Reconnect or repoint the broken link. Restore and reconnect the dropped webhook, or replace the corrupted config value with the correct single value pointing at this environment's resource. This is the smallest fix for one dropped connection or one bad string. [216][2216]
2. Pin per-environment settings as sticky. Mark each environment-specific value — connection string, return URL — as sticky so a shared slot cannot let settings bleed together and take the app down at boot. [2216]
3. Give each environment its own webhook endpoint and signing secret. Create a dedicated endpoint with its own signing secret per environment so pre-prod can receive callbacks without colliding with production. [2216]
4. Roll back the cutover. If the fault resists isolation, revert the migration/deploy to the last known-good state, restore service, then re-attempt the cutover with the fixes above staged in.

Escalate to integration escalation when:

• The webhook or connection string cannot be restored from your side. [216]
• Corrupted config keeps recurring after being fixed, pointing at the slot's sticky-setting policy. [2216]
• Environments keep colliding even after separate endpoints are configured. [2216]

• Confirm the webhook fires after its trigger event AND that the outcome tags or records write correctly. [216]
• Confirm the downstream workflows keyed off those records have resumed. [216]
• Confirm the service boots cleanly with the corrected sticky config value. [2216]
• Confirm pre-prod receives its callbacks on its own endpoint without colliding with production. [2216]

Recovery is complete only when each dependent consumer sees the expected effect — not when the webhook merely fired. [216]

• The config value the service booted with, showing the concatenation versus the corrected single value. [2216]
• The webhook wiring before and after reconnection, and which downstream workflows had stalled. [216]
• The per-environment endpoints and signing secrets after isolation. [2216]

Downstream-owner comms template:

A recent deploy dropped one integration, so some records stopped being written and a few dependent workflows paused. We have reconnected it and confirmed records are writing again and those workflows have resumed. If your workflow was affected, no action is needed on your side.

Run a retro and link it from the incident record. Lock in prevention:

• Verify each downstream consumer after a change, not just that the webhook fires. [216]
• Pin every per-environment setting as sticky so shared slots cannot bleed config. [2216]
• Give each environment its own webhook endpoint and signing secret. [2216]
• Keep a known-good rollback point for every cutover so recovery is fast when isolation fails.