Slack error service_unavailable: Service temporarily unavailable

The documented description is the complete story: "The service is temporarily unavailable". Slack could not serve the request right now — a deploy, a degraded dependency, a partial outage — and expects you back later. Unlike fatal_error and internal_error, there is no partial-success caveat in the documentation, but for mutating operations the safe posture is the same: prefer idempotent retries (client_msg_id on sends) over blind ones.

Operationally, treat it as availability weather. Single occurrences: retry with backoff and move on. Clusters: consult Slack's status page, engage your circuit breaker, and let queues hold noncritical traffic until the platform recovers. What you must not do is convert an availability dip into a self-inflicted rate-limit problem by retrying in a tight loop — pace retries, cap attempts, and de-duplicate whatever piles up in the queue during the outage.

If your bot is user-facing, degrade visibly: a status note or delayed-delivery marker beats messages silently arriving an hour late with no explanation.

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

Assume the dependency will blink: circuit breakers, bounded queues, and idempotent sends turn Slack outages into delays instead of incidents of your own. Rehearse the recovery path — draining a held queue at a pace that stays within rate limits — before you need it, because an untested drain either double-posts or trades one outage for a throttling penalty. A small amount of chaos testing against a stubbed Slack API pays for itself the first real incident.