What to Do When Slack Is Down

When Slack fails, the first job is to keep people coordinated. Save unsent messages, stop resending uncertain ones and move urgent communication to a channel your team can actually reach. One clear fallback is more useful than five improvised conversations.

Check the official Slack System Status page for the affected feature. If only one client or network seems broken, use Is Slack down? to narrow the problem before asking the entire team to move.

Stop retries and preserve unsent work

Copy important drafts into a local note before reloading or signing out. Record which messages or uploads have uncertain delivery. A spinner is not reliable proof that the recipient received nothing.

Do not keep sending the same urgent announcement in several channels. Ask one reachable colleague whether it arrived, using an alternative route if needed. Mark any replacement message clearly so it does not look like a separate instruction when both copies appear later.

Avoid broad app resets as the first response. If the browser works and the desktop app does not, preserve drafts and use the working client temporarily. Slack's connection troubleshooting guidance provides targeted checks for client and network problems.

Confirm impact and announce one fallback

Determine whether the problem affects login, message delivery, notifications, files or huddles. Ask a teammate to confirm the same action from another client or permitted network. Record the difference between a suspected issue and an official incident.

Send the announcement through a channel people can receive, such as an established email list, phone tree or approved secondary chat. Use a message like this:

Slack [feature] is affecting [team/workspace] as of [time and timezone]. Use [fallback location] for urgent coordination. [Owner] is following the official incident or investigating the cause. Please keep decisions in [record]. The next update is planned for [time].

Do not rely solely on Slack to announce that Slack is unavailable. If some users remain connected, ask them to relay the fallback location, but verify that critical people have received it through a working route.

Keep the team in one place

Choose an existing approved channel and name an owner for updates. State which work is urgent, where decisions will be recorded and when the team will check in again. A fallback that everyone already knows is easier to use than a new service introduced during the interruption.

For an active production incident, use the established on-call contact method. Confirm receipt from the people needed for the response. An unanswered message in a broken chat client is not a completed escalation.

Keep sensitive information within approved tools. If a fallback supports voice but not a persistent record, have someone maintain a short decision log. Include owners and actions so the later Slack summary can be accurate.

Continue work that does not require immediate replies

Use the team's existing issue tracker, documents or repository if they are available. Finish a focused development task, review an existing change or write the decision you were about to discuss. Keep pending questions in one place rather than scattering them across personal notes and email threads.

Avoid treating silence as approval. If a release or access change requires a specific review, obtain it through the agreed fallback or wait. The communication outage does not remove the need for the decision.

Make asynchronous updates clear enough to stand alone. State the task, result, remaining question and owner. That helps people catch up without reconstructing every conversation once Slack returns.

Adapt to the feature that failed

If only notifications are unreliable but messages arrive, agree on deliberate checks of a designated channel. Make urgent escalation explicit. Do not assume everyone saw a message because it appears in your own client.

If login or SSO is affected, keep working sessions available and involve your identity administrator where appropriate. Avoid organization-wide authentication changes based on an unconfirmed rumor.

If huddles are broken, use an existing approved meeting or phone option and share one destination. If file uploads fail, use your established document storage with the correct access permissions. If search is unavailable, use known conversation links or ask the owner for the relevant record instead of reposting private information broadly.

Track updates without constant refreshing

Have one person follow official notices. Downdetector and social posts can corroborate similar symptoms, but they cannot tell you whether a particular message arrived or whether your workspace has recovered.

Read incident details rather than just the headline. The status-page guide explains why partial recovery and individual client problems can coexist. Keep the fallback active until you have tested the communication path your team needs.

Reconcile messages and decisions after recovery

1. Confirm a test message can be sent and received by another person.
2. Check the affected feature separately, including notifications, files or huddles.
3. Review messages and uploads whose delivery was uncertain before resending them.
4. Post a concise summary of decisions made in the fallback channel.
5. Include owners, deadlines and links to the durable records.
6. Announce the return to normal communication in both locations.
7. Keep urgent follow-ups assigned until their recipients acknowledge them.

Avoid dumping an entire fallback transcript into Slack. Publish the decisions and outstanding actions people need. Record any gaps in the contact list or escalation process while they are fresh.

An optional break after coordination is covered

If the team has a working fallback and someone owns updates, join the Nines ping list. Nines is a tiny browser arcade that opens during qualifying official developer-tool outages. Yellow or degraded status alone does not open it.