🚨 Slack Error: 'internal_error' — Cause, Fix, and Troubleshooting Guide

Overview

internal_error means Slack encountered a transient problem on its side while handling your otherwise valid request. Like fatal_error, it signals a server fault rather than a client mistake.

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

Symptoms

• Sporadic failures on stable code paths, often bunched together in time.
• Retrying the identical request shortly afterward succeeds.
• No argument, scope, or auth change explains it.

Common Root Causes

1. Temporary Slack service degradation

A brief blip in a Slack subsystem returns internal_error for a slice of requests.

2. Downstream service timeout

Methods that depend on internal services (search, files, admin APIs) surface internal_error when a dependency times out.

3. Load spikes

During heavy load, a small fraction of requests can fail internally and clear on retry.

How to diagnose

Confirm it is transient by retrying and checking status:

curl -s -X POST https://slack.com/api/chat.postMessage \
  -H "Authorization: Bearer $SLACK_BOT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"channel":"C0123456789","text":"probe"}'
sleep 3
curl -s -X POST https://slack.com/api/chat.postMessage \
  -H "Authorization: Bearer $SLACK_BOT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"channel":"C0123456789","text":"probe"}'

curl -s https://status.slack.com/api/v2.0.0/current | head -c 300

A green status page plus success on retry confirms a one-off server hiccup.

Fixes

• Retry with exponential backoff and jitter. Treat internal_error as a retryable class alongside fatal_error, service_unavailable, and request_timeout.
• Use an idempotency/dedupe key so retries don’t duplicate side effects (double-posted alerts).
• Bound the retries and surface a real alert only if failures persist past your window.

What to watch out for

• Do not lump internal_error in with argument errors — those never clear on retry, so retrying them just wastes calls and can trip rate limits.
• Watch for correlation with rate limiting: a 429 (ratelimited) needs Retry-After handling, not blind backoff.
• Keep request timestamps in logs so you can line failures up against the Slack status timeline.

Related

• Slack Error: ‘ratelimited’
• Slack Error: ‘invalid_payload’
• Surviving Slack API rate limits