PagerDuty Full-Service Ownership Documentation


As the complexity of environments continues to increase, bringing accountability directly into the hands of the engineers for the code and services they create becomes a competitive advantage.

Enabling individuals and teams to own their code allows organizations to function on the edge of the customer experience, reduce the impact of disruptions, and focus on innovation.

The full-service ownership methodology brings agile and devops best practices to engineers providing them the ability to ensure the reliability of their systems and services through a deeper understanding of how their code functions in production.

Who Is This For?#

This resource is for team members working in any industry who want to deliver high quality experiences for cutomers, and keep systems running through enablement and owenrship of code.

What Is Covered?#

What is Full-Service Ownership?#

The who, what, when, how, and why of full-service ownership.

Implementing Full-Service Ownership#

Successfully adopting full-service ownership includes understanding agile practices, the value to the company, and the value to the customer. This section outlines factors individuals, teams, and organizations need to take into consideration.

How to go on-call#

You’ll learn the basics of going on-call, and best practices around being prepared for the unexpected.

After On-Call#

What to do once an on-call shift is over.

Additional resources#

Links to other helpful retrospective facilitation tips and tools.


This documentation is provided under the Apache License 2.0. In plain English that means you can use and modify this documentation and use it both commercially and for private use. However, you must include any original copyright notices, and the original LICENSE file.

Whether you are a PagerDuty customer or not, we want you to have the ability to use this documentation internally at your own company. You can view the source code for all of this documentation on our GitHub account, feel free to fork the repository and use it as a base for your own internal documentation.