rate limit hit mid-playbook execution: save plays failed to send

TL;DR

A playbook that generates save plays faster than the messaging or CRM API allows will lose the overflow if sends are fire-and-forget. Put sends on a durable queue, pace them under the limit with backoff on 429s, and confirm each play's delivery id back into the play record so undelivered plays are retried, never assumed sent.

rate limit hit mid-playbook execution: save plays failed to send

Use this when

• Save plays exist in the system but recipients never got them
• Send failures cluster at peak playbook volume
• No per-play delivery confirmation is recorded

Not for this skill when

• The plays were held by an approval workflow, not by sending
• The messaging channel itself was down for all senders

Steps

1. Reconcile generated plays against delivered messages for the affected window. Verify: the lost plays are enumerated exactly
2. Read the send path's rate limit behaviour: what happens on a 429 today. Verify: the drop point for overflow plays is located in code
3. Move sends behind a durable queue with pacing and header-aware backoff. Verify: a load test at peak volume now delivers everything, slower but complete
4. Record delivery confirmation per play and alert on plays undelivered past a threshold. Verify: delivery becomes a verified state per play
5. Re-send the lost plays with a note where timing made the original message stale. Verify: affected customers get the play, honestly framed

Variant phrasings

save plays not sent rate limit

A related phrasing for the same underlying problem.

playbook sends dropped under load

A related phrasing for the same underlying problem.

durable queue for play delivery

A related phrasing for the same underlying problem.

Compatibility: Compatibility: playbook engines sending via CRM, email, or Slack APIs with enforced rate limits, current versions.

Why it happens

Generation is cheap and bursty; delivery is rationed. Any design that couples them directly loses work at exactly the busiest, most important moments. A queue with confirmations is the boring, correct bridge between the two rates.

Edge cases / pitfalls

• Re-sent plays need a freshness check: a save play for an account that already renewed is worse than none.
• Pacing should respect the strictest limit among the APIs in the send path, usually the CRM write, not the email send.
• Delivery confirmation from the API means accepted, not read. Track acceptance here and engagement separately.

Provenance

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

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

Thread query: rate limit hit mid-playbook execution: save plays failed to send

TL;DR: A playbook that generates save plays faster than the messaging or CRM API allows will lose the overflow if sends are fire-and-forget. Put sends on a durable queue, pace them under the limit with backoff on 429s, and confirm each play's delivery id back into the play record so undelivered plays are retried, never assumed sent.