outreach agent sent a follow-up to a candidate who already declined - the ATS webhook for status changes wasn't firing

TL;DR: Check webhook delivery health before trusting cached stage, and do a live ATS stage read right before every outreach send. The follow-up went to a declined candidate because status-change webhooks were the only update path and they died silently. Monitor the pipe itself, not just the work it carries.

outreach agent sent a follow-up to a candidate who already declined  -  the ATS webhook for status changes wasn't firing

1. Check webhook delivery status in the ATS dashboard and your endpoint logs.

Expected: deliveries failing, the subscription paused, or the endpoint returning errors.

1. Fix the endpoint or re-subscribe, then replay the missed status-change events.

Expected: the candidate's stage updates to declined in the agent's records.

1. Add a pre-send stage gate: every follow-up does a live ATS read of the candidate's stage, and terminal stages block the send.

Expected: in a test against a declined candidate, the gate stops the email.

1. Add a dead-man's switch: if no status-change events arrive for a job in 24 hours on a business day, alert the team.

Expected: the alert fires during a simulated webhook outage.

1. Maintain a suppression list of terminal stages and check it at send time regardless of webhook state.

Expected: declined, rejected, and hired candidates are excluded even with webhooks fully down.

Use this when

• Outreach reaches candidates in terminal stages (declined, rejected, hired).
• The agent caches candidate stage and depends on webhooks for updates.
• Webhook delivery is unmonitored.

Not for this skill when

• The webhook fired and the agent processed it but still sent (that is a sequencing bug in the agent, not a delivery failure).
• The stage was wrong in the ATS itself.
• The candidate declined after the follow-up was correctly sent.

Variant phrasings

• follow-up email sent to a candidate who already declined
• outreach agent did not know the candidate said no
• status change webhook stopped firing and outreach kept going
• declined candidates still getting sequenced emails

Why it happens

The outreach agent cached stage at campaign start and subscribed to webhooks as its only freshness mechanism. Webhook delivery is best-effort: subscriptions pause, endpoints break, secrets rotate. When the pipe went quiet, the agent read silence as "nothing changed" instead of "I have stopped hearing anything." Emailing a candidate who said no is the kind of error that costs trust, so the send-time gate matters more than the cache.

Edge cases

• Webhook delayed vs dead: a delayed event eventually arrives and a dead one never does. The dead-man's switch distinguishes them by time, and the pre-send gate covers both.
• The candidate declines between the pre-send check and the send: keep that window seconds long and accept the residual risk.
• Custom terminal stages per job: the suppression list must be per-workflow, or a renamed stage slips through.
• Re-applied candidates: someone declined in March who reapplies in October is a new opportunity, not a suppression hit. Key suppression on the application, not the person.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_H9HgQvxCLIdlKAQEZQyrCg