Telemetry

Current Incident Response plugin version: v0.4.0

This document describes the motivation behind the telemetry in the Incident Response plugin and details what information is sent to Mattermost. This document is updated with every release of the Incident Response plugin.

1 Why do we track?
2 How do we track?
3 What do we track?
- 3.1 Metadata
- 3.2 Events data

Why do we track?

We hope to go through rapid iterations during the beta phase based on quantitative and qualitative feedback. In exchange for early access to the product, we would like to collect usage data so the feedback cycle isn’t bottlenecked by email exchanges and meeting schedules. As the product moves to general availability, we will re-evaluate the telemetry strategy to give customers the choice to opt out.

How do we track?

Our servers host an instance of Rudder, an open-source Segment alternative. The Incident Response plugin sends all the information from the events we track in real-time to Rudder, which in turns sync every thirty minutes with our Snowflake storage for further processing.

The data is then analyzed by Mattermost staff and is never shared with third parties.

What do we track?

During beta early access, events for the Incident Response plugin are collected regardless of the server telemetry configuration. In other words, even if telemetry is disabled in your Mattermost server, the information described on this page is still collected.

We only track the events that create, delete or update any items. We never track the specific content of the items. In particular, we do not collect the name of the incidents or the contents of the checklist items.

Metadata

Every event we track is accompanied with metadata that help us identify each event and isolate it from the rest of the servers. We can group all events that are coming from a single server, and if that server is licensed, we are able to identify the buyer of the license. The following list details the metadata that accompanies every event:

diagnosticID: unique identifier of the server the plugin is running on.
serverVersion: version of the server the plugin is running on.
pluginVersion: version of the plugin.
Fields automatically generated by Rudder:
- eventTimeStamp: timestamp on when the event was queued to send to the server.
- createdAt: timestamp on when the event was sent to the server.
- id: unique identifier of the event.
- event integrations: unused field. It always contains the value null.
- event originalTimestamp: timestamp on when the event actually happened. It always equals eventTimeStamp.
- type: type of the event. It always contains the string ”track”.

Events data

The following table details every bit of information sent to the Mattermost servers within each event:

Event	Triggers	Information collected

Event	Triggers	Information collected
Incident created.	Any user sends the `/incident start` command and creates an incident. Any user clicks on the `+` button on the Incident list view, in the RHS and creates an incident. Any user clicks on the drop-down menu of any post, clicks on the `Start incident` option and creates an incident.	`ID`: unique identifier of the incident. `IsActive`: boolean value indicating if the incident is active. It always equal `true`. `CommanderUserID`: unique identifier of the commander of the incident. It equals the identifier of the user that created the incident. `TeamID`: unique identifier of the team where the incident channel is created. `CreatedAt`: timestamp of the incident creation. `ChannelIDs`: a list containing a single element, the channel created along with the incident. `PostID`: unique identifier of the post . `NumChecklists`: number of checklists. It always equals `1`. `TotalChecklistItems`: number of checklist items this incident starts with. It always equals `0`.
Incident finished.	Any user sends the `/incident end` command. Any user clicks on the `End incident` button through the incident details view, in the RHS.	`ID`: unique identifier of the incident. `IsActive`: boolean value indicating if the incident is active. It always equal `false`. `CommanderUserID`: unique identifier of the commander of the incident. `UserID`: unique identifier of the user that ended the incident. `TeamID`: unique identifier of the team where the incident channel is created. `CreatedAt`: timestamp of the incident creation. `ChannelIDs`: a list containing a single element, the channel created along with the incident. `PostID`: unique identifier of the post. `NumChecklists`: number of checklists. It always equals `1`. `TotalChecklistItems`: number of checklist items this incident had when it ended.
Checklist item created.	Any user creates a new checklist item through the incident details view, in the RHS.	`IncidentID`: unique identifier of the incident where the item was created. `UserID`: unique identifier of the user that created the item.
Checklist item removed.	Any user deletes a checklist item through the incident details view, in the RHS.	`IncidentID`: unique identifier of the incident where the item was. `UserID`: unique identifier of the user that removed the item.
Checklist item renamed.	Any user edit the contents of a checklist item through the incident details view, in the RHS.	`IncidentID`: unique identifier of the incident where the item is. `UserID`: unique identifier of the user that edited the item.
Checklist item moved.	Any user moves the position of a checklist item in the list through the incident details view, in the RHS.	`IncidentID`: unique identifier of the incident where the item is. `UserID`: unique identifier of the user that edited the item.
Unchecked checklist item checked.	Any user checks an unchecked checklist item through the incident details view, in the RHS.	`IncidentID`: unique identifier of the incident where the item is. `UserID`: unique identifier of the user that checked the item.
Checked checklist item unchecked.	Any user unchecks a checked checklist item through the incident details view, in the RHS.	`IncidentID`: unique identifier of the incident where the item is. `UserID`: unique identifier of the user that checked the item.
Playbook created.	Any user clicks on the `+ New Playbook` button on the backstage and saves it.	`PlaybookID`: unique identifier of the playbook. `TeamID`: unique identifier of the team where the playbook is created. `NumChecklists`: number of checklists this playbook starts with. `TotalChecklistItems`: number of checklist items, among all checklists, this playbook starts with.
Playbook updated.	Any user clicks on the `Edit` button next to a playbook on the backstage and saves it.	`PlaybookID`: unique identifier of the playbook. `TeamID`: unique identifier of the team where the playbook lives. `NumChecklists`: number of checklists this playbook has after the update. `TotalChecklistItems`: number of checklist items, among all checklists, this playbook has after the update.
Playbook deleted.	Any user clicks on the `Delete` button next to a playbook on the backstage and confirms.	`PlaybookID`: unique identifier of the playbook. `TeamID`: unique identifier of the team where the playbook lived. `NumChecklists`: number of checklists this playbook had right before the deletion. `TotalChecklistItems`: number of checklist items, among all checklists, this playbook had right before the deletion.

DevOps Command Center