RigD.io Collaborative Automation for Incident Management
Find PagerDuty On Call from Slack in under 10 seconds
SlackOps for PagerDuty Part 2
This is the second installment of our series to help you master your incident management. As a reminder, read PagerDuty’s incident response documentation, as our series will generally follow how to operationalize, within Slack, the aspects of that documentation.
For part 2 we will be focusing on “Who’s on call” this is a step you will likely need to conduct one or more times during an outage when you need to engage other groups. It’s also a common task even outside the context of an incident. Our customers check on call an average of 56 times a month. Let’s get started.
Step 1 A Simple Question: Who is on Call in Pagerduty?
With the account connected it’s time to find out who is on call. To do this we will send a message to RigD,
who is on call?
In fact there are several ways you can ask, but that one is pretty easy to remember.
When prompted simply provide the name of the service or team you want to get on call details for and there you have it on call details in Slack in just a few seconds! Now if you are an over achiever follow along with the next section and see how you can get the details even faster and simpler.
Step 2 Automate Who is on Call from Slack
As we did in Part one when automating opening an incident we are going to create what we call a flow to speed the task up even more. It’s going to be a simple flow that does one thing, get the on-call details for a specific team, service, or PagerDuty escalation policy. Then we are going to create an alias which allows you to run the flow with some letters or words of your choosing. We made the setup of this very simply by providing a simple activity. Start by accessing the PagerDuty help by typing
help with pagerduty
Then choose the Get On Call button
There are a few questions to answer to complete the setup. Starting with which element you are looking for on call for.
Next provide the name of that team, service, or escalation policy.
Now it’s time to pick the alias test. I will again caution you to use something easy to remember. You can’t effectively use what you don’t easily remember.
The last question to answer is optional. In some companies teams or services have dedicated channels. it can be very convenient to set the topic of these channels with the on call details. That way anyone looking for help can quickly see who to reach out to just by going to the team or service channel. Choose an existing channel to set the topic for and we will make sure it’s kept up to date.
Your Flow and alias has now been set up. Let’s give it a try. Remember that to use an alias you have to start by typing ! then adding the alias text. This helps us avoid accidentally running something based on random chitchat.
If you chose to set the on topic in a channel then you will see that updated every 15 minutes with the latest on call details.
Well that is it. You can now get your on call details from within Slack in about 3 seconds! If you recall from part 1 we calculated the potential time savings from using RigD to open an incident. Let’s extend that to add this second part. Again we have 7 major incidents per month and an average cost per minute of downtime for an enterprise at $5,600. Without RigD getting on call through the PagerDuty UI takes around 28 seconds and with RigD its 3–9 seconds. So checking on call just once during each of those incidents in that month then adds a potential cost of $18,293 without RigD and $1,960 if using RigD. Adding the two tasks together we have a total potential monthly outage cost without RigD of $41,813 and just $8,493 with RigD. The potential savings are starting to add up and we have only covered two tasks.
Stay tuned for our next installment which will cover automatically opening dedicated incident Slack channels.
Learn more about RigD here.