When Can A Service Not Be a Service?
If you’re familiar with PagerDuty, you probably associate it with alerts about technical services behaving in ways they shouldn’t. Maybe you yourself have been notified at some point that a service wasn’t available, was responding slowly, or was returning incorrect information. That’s the common use of a service in the PagerDuty platform.
We define services as:
A technical service reflects a discrete piece of functionality that is wholly owned by one team. One or more technical services combine to deliver customer-facing or business capabilities.
But there are other uses of a service in PagerDuty. A service in the PagerDuty platform is an object that can receive inbound information. That information might come from any number of integrations, partner tools, or human inputs, and PagerDuty helps decide what to do about that information in the context of the service.
Expanding our understanding of the service metaphor means we can achieve so much more than uptime monitoring.
So, while many PagerDuty services are reflections of real-life technical services, there are other ways to use the service metaphor for routing and decision-making based on that incoming data.
Information from an External Source or SaaS
PagerDuty has a number of integrations that are primarily used to report information about a process running in another service. These sort of look like technical services. The PagerDuty services are set up to receive information from an external source and get it to your teams. These types of service-but-not-a-service are a great place to collect data from different apps in your workflow and manage it in a single place. Security integrations in particular often work this way.
For example, PagerDuty’s integration with JFrog Xray reports security vulnerabilities as the output of Xray scans running in your JFrog environment. Xray sends information to PagerDuty via the integration to report on its findings. Your team can decide how best to manage these kinds of information sources. It may make sense to have all security scans report to one PagerDuty service, maybe Important Security Scans, and assign that service to your security team, or to individual PagerDuty services that are assigned to the teams that own the application being scanned. The flexibility of the service object lets you decide how to get the correct information to the teams who are ultimately responsible for fixing any issues.
Status of an Object
A service in PagerDuty can also represent the status of an object somewhere in your ecosystem. Folks working in IoT environments, or with sensor networks, or other similar components can utilize PagerDuty to report on the state of the environment.
Anything that can make an HTTPS request can send data to a PagerDuty account. So, while most folks don’t have a refrigerator that will let them know when the milk is low, a commercial refrigeration system can alert someone via PagerDuty if the temperature is outside of the acceptable range. PagerDuty customer Good Eggs does just that. You can learn more about their use case on the PagerDuty website.
Actions or Activities
PagerDuty services can also be used to coordinate an action or activity outside of your application. Any action your team might need to be informed on (such as offboarding an employee) can be run through PagerDuty. We’ve been collecting some solutions for non-technical teams who use PagerDuty for work that need to be completed quickly. When a task or request can’t be lost in email, send a PagerDuty notification.
You can find some of these ideas on our Business Guides site.
Coordinating employees across your organization for a single activity can be challenging, and using a service can aid in that coordination. At PagerDuty, we use Incident Commanders (ICs) to coordinate the response for SEV-1 and SEV-2 incidents. The ICs might be folks from all over the company who have volunteered and trained via our Incident Commander training. They aren’t all on a single team, so how do we alert them?
In our case, we have a service, Major Incidents, that is linked to the Incident Commander escalation policy. Because we use this model, the Major Incidents service can be included in response plays and connected to extensions like Slack. Whenever a high severity incident is declared, an incident is created on the Major Incidents service, ICs are notified, stakeholders are notified, and Slack channels are created.
Using a service object as a metaphor for an action opens up a world of possibilities for coordinating resources and communicating in real time.
Have Another Idea?
We’d love to hear all about it. Come show off your inventive uses of PagerDuty on our Twitch channel. If you’d like to be a guest on one of our shows, send us an email at community@pagerduty.com.