# Slack status

> Is Slack down? Live status, uptime history, and per-region response times for Slack's API, measured by our own probes rather than user reports.

Published: 2026-08-19 | Canonical: https://yoping.me/status/slack

## How we check Slack

We watch slack.com/api/api.test from all five of our probe regions, every 2 minutes. A region that sees a failure does not make this page say "down" on its own: a second region has to agree first, the same confirmation rule every YoPingMe monitor uses.

Slack publishes a method whose entire purpose is to confirm the API is reachable, and it answers without a token, so we can measure the platform without holding a credential that would eventually expire and report itself as an outage. It also exercises the same API surface that every integration, bot, and alerting webhook in your stack depends on.

The live board - the current verdict, 24-hour, 7-day, and 30-day uptime, and per-region response times - is on the HTML page at https://yoping.me/status/slack. Those numbers change too fast to repeat honestly in a static mirror, so where an answer below says "the board above", it means that page.

## What is Slack?

Slack is where a large share of internal communication happens, and for
many organisations it has absorbed roles that used to belong to email,
phone calls, and walking over to someone's desk. It is also, less
visibly, a piece of operational infrastructure. Deploy notifications,
monitoring alerts, on-call escalations, customer support handoffs, and
approval workflows all commonly terminate in a Slack channel, which means
an outage does not only make a company quieter. It can take out the way
that company finds out about its other problems.

That second role is the one worth thinking about in advance. A monitoring
system whose only alert channel is Slack has a dependency that nobody
usually writes down, and the failure is silent in the worst way: no alert
arrives, and the absence of an alert is indistinguishable from everything
being fine. Teams tend to discover this during their first significant
Slack incident, which is also the moment when several other things are
often going wrong at once. Any alerting path worth trusting has a second
channel that does not share infrastructure with the first.

From the outside, Slack incidents tend to be partial rather than total.
Sending messages, loading history, uploading files, running slash
commands, and delivering API events are separate operations, and it is
routine for one to degrade while the rest work. The visible result is a
client that mostly works with one thing conspicuously broken, which reads
to most users as their own machine misbehaving rather than a platform
problem. That instinct sends people restarting the desktop client, which
is a reasonable first move and a poor second one.

The desktop client deserves a mention of its own. It maintains a
long-lived connection and caches a lot of state, so it can get stuck in
ways the browser version does not. When one person cannot load a
workspace their colleagues are using normally, the client is a more
likely explanation than the platform, and opening the same workspace in a
browser separates the two in seconds.

For anyone building on Slack rather than only using it, the API is the
part to watch, which is why this page measures that rather than the
marketing site. An integration that has stopped posting is usually
looking at a token that was revoked, a scope that changed when someone
reinstalled the app, or a rate limit reached after an automated burst,
and none of those will ever appear on a status page. Knowing that the
platform is answering normally is what narrows the search to your own
side of the connection.

## Frequently asked questions

### Is Slack down right now?

Check the board above; it reflects our own probes against Slack's API from all five of our regions, refreshed every couple of minutes and confirmed across two regions before this page would call it down.

### Slack will not load for me but my colleagues are fine. What is wrong?

Almost certainly something local rather than Slack. A workspace is served the same way to everyone in it, so a problem affecting one person and not their colleagues usually points at the desktop client holding a stale connection, a corporate proxy or VPN interfering, or a DNS resolver returning an old answer. Opening the workspace in a browser is the quickest test, since it bypasses the desktop client entirely.

### Why did my Slack alerts stop arriving during an incident?

Because the alerting path runs through Slack's API, which is exactly what a Slack outage takes out. This is worth planning around rather than discovering live, since a monitoring setup whose only notification channel is Slack goes silent at the moment you most need it. Keeping a second channel, email or a webhook to something that does not depend on Slack, is the standard fix.

### Do Slack outages affect messages already sent?

No, sent messages are not lost. What typically happens during an incident is that new messages fail to send, appear to send and then show a retry indicator, or arrive out of order once the connection recovers. History is preserved, and the client usually reconciles itself within a few minutes of the platform recovering.

### My Slack app or bot is failing but Slack itself works. Where should I look?

Look at the API responses your app is getting before assuming a platform problem. Slack returns a descriptive error string for each failed method call, and the common ones during normal operation are an expired or revoked token, a missing scope after a permissions change, or rate limiting after a burst of posts. If the board above shows the API answering normally, one of those is much more likely than an outage.