As a general principle, we try to 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.
💡How we store chat messages
By default, we store Slack messages that are pinned to the incident timeline. For other messages in incident channels we only store the ID of the message, who sent it, and when, which lets us calculate workload insights.
If you'd prefer we never store any messages, you can disable this in Security settings, and we'll delete any message data we're storing. If you disable storing channel messages:
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.
We won't be able to show you a full timeline in incident.io if the incident channel has been archived.
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 incident.io 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.