> For the complete documentation index, see [llms.txt](https://docs.aviator.co/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.aviator.co/flexreview/how-to-guides/pagerduty-integration-for-reviewers.md).
# PagerDuty Integration for Reviewers
{% hint style="info" %}
This feature is currently available only for on-prem users.
{% endhint %}
Teams can configure their assignment method to use PagerDuty schedule. To use PagerDuty assignment, the on-prem server administrator needs to do one-time setup on the server.
## OnPrem Server Setup
You need to create a PagerDuty App for your Aviator installation. In the Integration menu, you can find App Registration link.
Create a new app with OAuth 2.0 functionality. In the permission settings, check Scoped OAuth and give read access to following 4 resources:
* Escalation Policies
* Oncalls
* Schedules
* Users
You will see the client ID and secret. Set them as the environment variables for the Aviator server:
* PAGERDUTY\_CLIENT\_ID: The client ID of the registered app.
* PAGERDUTY\_CLIENT\_SECRET: The client secret of the registered app.
* PAGERDUTY\_REGION: "us" or "eu". See to check which one your PagerDuty account is in.
* PAGERDUTY\_COMPANY\_SUBDOMAIN: The subdomain part of your PagerDuty page. If you have `https://acmecorp.pagerduty.com`, set `acmecorp`for this variable.
Restart the server to reflect the environment variable changes.
## Assignment Config
Once the server setup is done, you can see the oncall assignment option in the team config page.
Set the ID of the escalation policy. If your PagerDuty escalation policy page's URL is `https://acmecorp.pagerduty.com/escalation_policies/PCR31GJ` then `PCR31GJ` is the escalation policy ID.
## PagerDuty user to GitHub username association
The Aviator server gets the email address of the oncall. Based on this email address, it looks up the user in the Aviator user database. In order to assign them as a reviewer, each user needs to have their GitHub username registered. To do this, see [GitHub Integration](/mergequeue/how-to-guides/custom-integrations/slack-integration.md).
We can support batch creation and association of the users. Please contact us if you need this.
## Escalation policies and assignment
PagerDuty's escalation policy can have multiple levels. For example, once an incident happens, alert on the oncall of this schedule. Then after 15 minutes, escalate to this schedule. And so on. FlexReview will roughly follow this rule. It will assign somebody from the first level in the escalation policy. If it cannot find a user to assign, it will check the next level.
For example, with the following escalation policy:
FlexReview tries to assign the oncall of the schedule specified in the level one. If the oncall of that schedule doesn't have a GitHub user associated or if the PR author is that oncall person, it moves on to the next level. The second level has a single user, and it tries to assign that person as a reviewer. It keeps doing this until we find one. If it cannot find any, FlexReview will not assign anybody.
If there are multiple people in the same level, FlexReview will randomly pick one.
## Reviewer exclusion list
PagerDuty assignment rule will ignore the reviewer exclusion list configured at the repository. This is to avoid pull request being dropped without any assignment to the oncall.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.aviator.co/flexreview/how-to-guides/pagerduty-integration-for-reviewers.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.