Turn any signal into insight and action. See how PagerDuty Digital Operations Management Platform integrates machine data and human intelligence to improve visibility and agility across organizations.
Connect insights to real-time action by aligning teams through the shared language of business impact.
Check out the latest products we’ve been working on—including event intelligence, machine learning, response automation, on-call, analytics, operations health management, integrations, and more.
Digital Operations Management arms organizations with the insights needed to turn data into opportunity across every operational use case, from DevOps, ITOps, Security, Support, and beyond.
Over 300 Integrations
Discover DevOps best practices with our library of webinars, whitepapers, reports, and much more.
Learn best practices and get support help with resources from our award-winning support team.
See how PagerDuty works with our live product demo — twice a week, every week.
We've created a maturity model to assist on the journey to digital operations excellence. Take our short assessment to find out where your team falls!
Interactive, simple-to-use API and technical documentation enables users to easily try updates and extend PagerDuty.
Engage with users and PagerDuty experts from our global community of 200k+ users. Become a member, connect, and share insights for success.
Get all your PagerDuty-related questions answered by exploring our in-depth support documentation and community forums.
Have you ever worked on a team where it was a challenge to give constructive feedback or confidently share ideas? At PagerDuty Summit 2018, Patrick...
PagerDuty helps organizations transform their digital operations. Learn more about PagerDuty's mission and what we do.
Meet our experienced and passionate executive team.
We are risk-taking innovators dedicated to delivering amazing products and delighting customers. Join us and do the best work of your career.
With the PagerDuty Foundation, we are committed to doing our part in giving back to the community.
The typical techie will face every challenge with a simple question: “Can I build the solution myself?” And often, the question is valid enough that it gets some significant consideration. So, should we build or buy? Evaluation of an incident management solution seems to now invite this question as well. But how do you know when you should build or buy your incident management platform?
Sometimes the desire to build your own solution is based on the simple fact that procurement of a commercial solution is out of your hands. For example, enterprise IT has the budget for the tool, but the DevOps team needs it. It may seem easier to build a solution from open source projects than to play the long-term games it takes to get a solution purchased. But this is an organizational problem, and not a technical one. And often times, the custom-built solution tends to be short-lived.
But there are other reasons why you might want to build your own solution:
These are valid reasons to consider building your own incident management solution — but all need to be scrutinized.
Are your requirements truly unique? The way to identify if this is the case is to look at your competitors and what they use, and research your requirements compared to similar organizations. And at the same time, even if you have a unique requirement, you might want to question why it’s so unique. Does it need to be that way?
As for security, what is it about your security and privacy concerns that make them a no-go for commercial incident management? Is it the potential for exposed data? Most of the time, application data does not need to be included as part of alerts, but if it is, this is something to consider. If the concern is around security in general, keep in mind that vendors work to make sure they are current on security threats. Often, they have the capacity to be much more on top of security than internal operations teams.
And then there’s cost. Cost is tricky because the most expensive aspects of building your own solution are not easily calculated. It’s easy to calculate the monthly fee of an incident management service versus the cost to do one-time development from a full-time developer. However, it’s hard to anticipate on-going maintenance, feature changes, and the big one — opportunity cost. What would the developer(s) be working on if they were not building this solution? And what is the cost of having projects or backlogs put aside while it’s being developed? Another issue arises when the person who built it leaves, and takes the understanding of the code base with them. You don’t want tribal knowledge leaving the organization when it’s related to a mission-critical part of your infrastructure.
Building an incident management solution has one particular weak spot — integrations. Successful incident management platforms have a huge library of integrations into sources (like your application and infrastructure) and distribution (like your collaboration tools). Building these integrations takes quite a bit of time, oftentimes requiring developers to learn and build against new APIs. Organizations who build their own incident management platform may only have to work with integrations that matter to them, as they don’t need to support many use cases. But when the APIs for these systems change, you can be blindsided — miss out on new functionality or break the platform altogether. Open source projects are not going to respond as quickly to changes in integrations or create new ones, and if something breaks, your developer, already tasked with something else, would have to drop everything and address it. And of course, the choice of tooling that your incident management system must integrate with may also shift as the team scales and its needs change.
There is a scenario where a custom-built incident management platform based on open source projects is useful, and that’s when it is required for purpose-built, very niche scenarios. Generally, organizations that need such a solution would have commercial incident management for the global environment, and roll up or even integrate into the incident management platform’s API for the niche scenario.
The other purpose might be for alerting that is used in a different context than for application or infrastructure support. Perhaps the alerting is used for collaboration or product management. In such cases, it might be useful to segment the use case from the commercial and mission-critical incident management system with a more homegrown and less liable system for the other use cases. This can be true for teams that already have a lot of customization when it comes to learning from their application usage. For example, when a new feature is launched you can elect to receive alerts when that feature is used, or when new infrastructure is rolled out you can choose to be alerted when you hit a certain KPI in performance to understand the impact of the changes.
The other reason is data leak concerns, both internal and external. For example, alerts where remediation exposes personally identifiable information to internal tier 1 support, but they do not have the authority to see. This could be an issue, especially in regulated industries. Nine times out of 10 you can modify your roles in the platform and what is exposed, so this is never a problem. In general, you should always try to do that. But there are the rare instances where it is unavoidable.
A seasoned techie will know when it’s the right time to build or buy, beyond their interest to tinker and solve problems. The initial creation of the solution is not where you get stuck. It’s the long-term support, and risk associated with custom solutions. And it’s not just the creation of the solution — you also have to run it. Do you install an incident management system for your incident management system? Having to worry about the uptime of something else is stressful, and if incident management goes down, you are flying blind.
Custom niche integrations into your code base and infrastructure sometimes justify building your own incident management solution. Or if you have non-mission-critical use cases that are tangential to your commercial incident management, it may be worth the effort to build your own. In general, though, a commercial solution will have a lower total cost of ownership, will address your needs as you scale, will ensure that tooling and processes don’t break down when certain experts leave, and will have better coverage and solutions for your security and privacy concerns.
When deciding to build or buy, I suggest focusing heavily on the opportunity cost. This is the greatest unknown and expense, and usually, the answer becomes clear pretty quickly.
In the United States, it’s almost that time of year again where we count our blessings and give thanks. For retail workers, it’s also that...
A long time ago, back in the early days of 2017, we open-sourced our Incident Response Documentation, the reference point for all our internal processes...
600 Townsend St., #200
San Francisco, CA 94103
905 King Street West, Suite 600
Toronto, ON, M6K 3G9, Canada
1416 NW 46th St., St. 301
Seattle, WA 98107
5 Martin Place
1 Fore St,
London EC2Y 9DT
© 2009 - 2019