Go to Slack

Checking up on Slack with the Slack Status API

The Slack Status API describes the health of the Slack product. When there's an incident, outage, or maintenance, the Slack Status API reflects all the information we have on the issue, including which features of Slack are affected and detailed updates over time.

Atom and RSS Feed

Receive updates on the health of Slack services by subscribing to our Atom or RSS feeds. Use your favorite subscription tool to subscribe to https://status.slack.com/feed/atom or https://status.slack.com/feed/rss. You could even use the /feed command in Slack to subscribe to our Status feed — but it might not work if some parts of Slack are unavailable. An outside feed reader might be a better choice.

Note that many readers check for updates only a few times an hour. Set your feed reader to poll for updates often (for example, once a minute) if you need to be notified immediately of a Slack issue.

API reference

Slack offers two API endpoints to describe its status. Use the https://status.slack.com/api/current endpoint to check for an active incident. Use the https://status.slack.com/api/history endpoint to learn about past incidents. Both are unauthenticated: you can even open these API endpoints directly in your browser. Try it.

You can also find either endpoint with a simple cURL command:

curl https://status.slack.com/api/current
curl https://status.slack.com/api/history

Current Status API

The current endpoint returns a JSON object containing a "status" field. When all is well, the "status" will be "ok", and the response will be brief. Here's a sample "ok" response.

{
    "status":"ok",
    "date_created":"2018-09-07T18:34:15-07:00",
    "date_updated":"2018-09-07T18:34:15-07:00"
}

If there's an incident, outage, or planned maintenance, you'll receive a richer JSON response containing a title that describes the issue, a time updated, and affected services. Here's a sample JSON response describing an issue with email forwarding:

{
  "id": "546",
  "date_created": "2018-09-07T14:35:00-07:00",
  "date_updated": "2018-09-07T18:34:15-07:00",
  "title": "Slack’s forwarding email feature is failing for some customers",
  "type": "incident",
  "status": "active",
  "url": "https://status.slack.com/2018-09/7dea1cd14cd0f657",
  "services": [
    "Apps/Integrations/APIs"
  ],
  "notes": [
    {
      "date_created": "2018-09-07T18:34:15-07:00",
      "body": "Technical Summary:\r\nOn September 7th at 2:35pm PT, we received reports that emails were failing to deliver to Slack forwarding addresses. We identified that this was the result of an expired certificate used to verify requests sent from our email provider. At 4:55pm PT, we deployed an update that corrected this and fixed the problem. Unfortunately any email sent to a forwarding address during this time is not retrievable and will need to be re-sent."
    }
  ]
}

Here's more detail on each of the fields in the response:

  • id - A unique ID for the incident.
  • date_created - The timestamp when incident response or maintenance began.
  • date_updated - The timestamp when incident response or maintenance was most recently updated.
  • title - A short description of the issue.
  • type - The type of issue we're experiencing. The options are incident, notice, or outage.
  • status - We use status "ok" when all is well. Otherwise, the status field is "active" when the issue has not yet been resolved, and "resolved" when the issue has been resolved. The status may also be "scheduled," "completed," or "cancelled" in the case of planned maintenance.
  • url - A web URL tracking this incident. The information displayed is the same as in the API endpoint.
  • services - An array that lists the Slack services affected. We use these service names:
    • "Login/SSO"
    • "Messaging"
    • "Posts/Files"
    • "Calls"
    • "Apps/Integrations/APIs"
    • "Connections"
    • "Link Previews"
    • "Notifications"
    • "Search"
    • "Workspace/Org Administration"
  • notes - An array of notes with additional specifics and updates.

The current API endpoint only displays one incident at a time. If there are multiple incidents, it displays the most urgent one according to Slack internal incident ranking. If there are no active incidents, it'll display the most recent incident that was updated within the last hour. If no incidents have been reported or updated in the last hour, the endpoint returns the terse "ok" response.

History API

The history endpoint returns a list of all past Slack issues. Each object in the response array is an incident like the ones returned by the current endpoint. As with the current endpoint, you can expect the following fields for each issue:

  • id - A unique ID for the issue.
  • date_created - The timestamp when incident response or maintenance began.
  • date_updated - The timestamp when incident response or maintenance was most recently updated.
  • title - A short description of what's happening.
  • type - The type of issue. The options are incident, notice, or outage.
  • status - We use status "ok" when all is well. Otherwise, the status field is "active" when the issue has not yet been resolved, and "resolved" when the issue has been resolved. The status may also be "scheduled," "completed," or "cancelled" in the case of planned maintenance.
  • url - A web URL tracking this incident. The information displayed is the same as in the API endpoint.
  • services - An array that lists the Slack services affected. We use these service names:
    • "Login/SSO"
    • "Messaging"
    • "Posts/Files"
    • "Calls"
    • "Apps/Integrations/APIs"
    • "Connections"
    • "Link Previews"
    • "Notifications"
    • "Search"
    • "Workspace/Org Administration"
  • notes - An array of notes with additional specifics and updates.

Best practices

  • Call the current endpoint as frequently or infrequently as you need to in order to respond to issues with Slack; if you need to be notified immediately of an incident, consider polling the current endpoint once a minute. Polling more frequently than that isn't recommended.
  • If you rely on a specific feature of Slack heavily, check the services field of an incident to verify that the feature is working as usual. For example, if your app doesn't use link unfurls, but does rely on messaging, consider filtering for incidents that contain Messaging in the services array, and ignoring alerts that only affect Link Previews.