Calculating workload
We generate workload by watching activity taken in an incident — inferring activity as a signal that someone was actively working on that incident.
The rules are:
If we see incident activity, such as a message in the incident channel, or work in integrations like issue trackers, we'll assume the related person has spent 10 minutes working on this incident.
If the same user takes another action for the same incident within 20 minutes of the last, we'll assume they've been working on this incident continuously since the last time we saw them.
As an example, if we see someone message the incident channel at 10:11 am, we'll immediately assign them 10 minutes of workload. When we have access to participant data, we also include being a participant in an incident call as workload.
If that person were to update a Zendesk ticket attached to this incident at 10:15 am, we'll adjust to assume 4 min of activity (from 10:11 to 10:15) and allocate another 10 minutes after, for a total sum of 14 mins of work.
For the average responder focused on specific incidents, this provides an accurate picture of their time. But for incident managers who work across many incidents at a time, we apply a final calculation to trim their workload to ensure we never overlap workloads across incidents, preventing us from calculating more than one hour of work in any hour.
We're confident this calculation is representative of individual contributions and can be used as a valuable proxy for effort put into an incident.
Calculating working hours
The workload chart splits hours by:
Working: 8 am-7 pm
Late: 7 pm-11 pm
Sleeping: 11 pm-8 am
This is a dimension we apply to the calculated workload to understand when a period of work happened relative to the user's timezone, which we align with their Slack timezone at the point this workload is seen to have occurred.
Note: Working hours are not customizable