Slack error internal_error: Transient error on Slack's side

Slack hit an internal problem it describes as "likely due to a transient issue on our end," with the same caveat as fatal_error: "It's possible some aspect of the operation succeeded before the error was raised." Transient is the operative word — the expected outcome is that the identical request succeeds moments later — but the partial-success caveat still applies to anything that mutates state, so message sends deserve the verify-before-retry treatment rather than a reflexive resend.

In monitoring, a low background rate of internal_error is normal operating texture for any large platform; the signal worth alerting on is deviation — a spike concentrated in time (Slack incident) or concentrated on one payload (your edge case). Log the request ID/context with each occurrence so those two patterns are distinguishable in one query.

Handle with standard resilience: bounded exponential backoff, idempotency via client_msg_id on posts, and a circuit breaker so a Slack incident degrades your bot gracefully instead of building an unbounded retry queue that discharges as a thundering herd when service recovers.

{"ok": false, "error": "internal_error"}

Bake idempotent sends and bounded, jittered retries into your Slack client wrapper so every call path inherits them instead of reimplementing them inconsistently. Alert on error-rate deltas, not single events, and cap retry queues so a platform incident cannot snowball into a backlog that discharges all at once when Slack recovers — that discharge is how an availability blip turns into a self-inflicted ratelimited episode.