Security FAQs
Security FAQs

Security FAQs


Are you approved by Slack? has been approved by Slack and can be found in the Slack App Store here.

How do you authenticate users?

We currently use Slack as our sole authentication mechanism, meaning no additional authentication strategy or provider is required. However your organisation chooses to authenticate with Slack — whether that's directly or with a single sign-on provider — that same authentication mechanism is used to access

For the web application, temporary sessions are granted when you sign in with Slack. These periodically expire and are refreshed by redirecting the user through the OAuth flow. We can also revoke these tokens.

What Slack permissions and access scopes do you require?

As a workspace app, you can interact with from anywhere within Slack, but we’re careful with the permissions and scopes we require and request the minimum we need to function.

We can only access data in two places by default:

  • A nominated incident channel, such as #incidents (where incidents are summarised)
  • Individual incident channels, which we create on your behalf

We cannot access Slack data outside of these channels, unless our app is explicitly invited.

Specifically, we ask for permissions to:

  • app_mentions:read (so we know when you’re talking to us)
  • channels:history (so we can list messages in an incident channel)
  • channels:manage (so we can create and edit incident channels on your behalf)
  • channels:read (so we can list public channels)
  • chat:write (so we can talk to you)
  • commands (So you can trigger incidents in the workspace, and control actions in incident channel)
  • im:history (so we can read DMs that are sent to the bot)
  • pins:read (so we can help build your timeline from pinned items)
  • reactions:read (so we can build experiences based on emoji reactions)
  • reactions:write (so we can respond to messages with emoji)
  • users:read (so we can see basic information on a user in an incident)
  • (so we can lookup users by their email address)
  • groups:read (so we can view who is in any referenced groups)
  • users.profile:read (so we can render user information nicely in the app, timeline and post-mortem, using their name and avatar)
  • (so we can read images shared in an incident channel and display them in the incident timeline)


What data do you collect?

We generally collect as little information from you as required to do our job. Here is an exhaustive list of the data we currently collect from you, or from your workspace when you grant us access to Slack.

  • The name of your company, and the Slack Team ID of your Slack workspace. We use the installation to store an access token that grants us the permissions with the above scopes.
  • The name, Slack user ID and avatar URL of users who interact with the web app, or the bot.
  • A description of an action (a task that you would like someone to do during or after an incident), the current state of that action (outstanding, or completed), and who is assigned to be the owner of that action.
  • The name of an incident, the summary description of the incident, the severity of the incident, the URL of any document that you set to be associated with an incident, and the URL of any video conferencing call you set to be associated with an incident. We cannot view this document, or the call, as they are URLs: they should be internal to your organisation.
  • Who and when people joined or left incident channels (so we can determine who was involved in the incident at a particular time)
  • Who and when people sent messages in incident channels (so we can determine who is participating in the incident — we do not store the content of these messages)
  • Who and when someone pinned a Slack message
  • Who and when someone posted a message containing a link to a third party of interest (such as GitHub, or Sentry).


This does not include data that we create internally, such as autogenerated IDs that link all of entities together.

How do you store our incident data?

As a general principle, we try and minimise the amount of data that we store, and keep as much as possible in Slack. The majority of what we do is then built on top of Slack, dynamically pulling information on demand to provide a “view” on top of that.


Let's walk through how we store chat messages. We don't store any chat message content on servers — we store the ID of the message. When a request is made to view the timeline of the incident (which displays the content of the message) we ask Slack for the message content when serialising our response, and pass it to the dashboard. It is also cached in-memory for a few minutes to avoid hitting Slack's rate limits.

There are a few pieces of information and entities that we can’t realistically store or power directly with Slack, as they are specific to the application we have built. Examples include actions, the summary of the incident and account settings.

For these use cases, we store a minimal amount of data in our primary datastore (Postgres). All data is encrypted at rest and in transit throughout our system.

Where is our data stored?

For transactional data processing (interacting with the Slackbot, and viewing the dashboard, the data is hosted in Ireland, in eu-west-1.

For analytical data processing (for our internal analytical use case), data is stored within Europe.

We currently don't send any data outside of Europe.

Can you delete our data?

If you decide to stop using, we're happy to delete application data upon request. Just let us know.


What platform does run on?

Our primary web application and our Slack integration both run in the cloud on top of an established Platform called Heroku, which in turn is built on top of Amazon Web Services.

Any data we store is kept either in our Postgres database (also securely hosted and managed by Heroku), or our BigQuery instance inside Google Cloud Platform. All data is encrypted at rest in both Postgres and BigQuery.

Two-factor authentication is applied to both Heroku and Google Cloud Platform.