pagerduty ¤
admin ¤
models ¤
PagerDutyEscalationPolicy ¤
Bases: Model
An Escalation Policy determines what User or Schedule will be Notified and in what order. This will happen when an Incident is triggered.
Escalation Policies can be used by one or more Services.
Escalation Rules
- An Escalation Policy is made up of multiple Escalation Rules. Each Escalation Rule represents a level of On-Call duty.
- It specifies one or more Users or Schedules to be notified when an unacknowledged Incident reaches that Escalation Rule.
- The first Escalation Rule in the Escalation Policy is the User that will be notified about the triggered Incident.
- If all On-Call User for a given Escalation Rule have been acknowledged of an Incident and the Escalation Rule's escalation delay has elapsed, the Incident escalates to the next Escalation Rule.
PagerDutyIncident ¤
Bases: Model
An Incident represents a problem or an issue that needs to be addressed and resolved.
Incidents can be thought of as a problem or an issue within your Service that needs to be addressed and resolved, they are normalized and de-duplicated.
Incidents can be triggered, acknowledged, or resolved, and are assigned to a User based on the Service's Escalation Policy.
A triggered Incident prompts a Notification to be sent to the current On-Call User(s) as defined in the Escalation Policy used by the Service.
Incidents are triggered through the Events API or are created by Integrations.
PagerDutyOncall ¤
Bases: Model
An On-Call represents a contiguous unit of time for which a User will be On-Call for a given Escalation Policy and Escalation Rule.
This may be the result of that User always being On-Call for the Escalation Rule, or a block of time during which the computed result of a Schedule on that Escalation Rule puts the User On-Call.
During an On-Call, the User is expected to bear responsibility for responding to any Notifications they receive and working to resolve the associated Incident(s).
On-Calls cannot be created directly through the API; they are the computed result of how Escalation Policies and Schedules are configured. The API provides read-only access to the On-Calls generated by PagerDuty.
PagerDutyOncallManager ¤
Bases: Manager['PagerDutyOncall']
get_current_oncalls_per_escalation_policy ¤
get_current_oncalls_per_escalation_policy() -> list[tuple[PagerDutyEscalationPolicy, list[PagerDutyOncall]]]
Returns the list of on call Users. These users have their PagerDutyUser associated.
Source code in src/firefighter/pagerduty/models.py
PagerDutySchedule ¤
Bases: Model
A Schedule determines the time periods that Users are On-Call.
Only On-Call Users are eligible to receive Notifications from firefighter.incidents.
The details of the On-Call Schedule specify which single User is On-Call for that Schedule at any given point in time.
An On-Call Schedule consists of one or more Schedule Layers that rotate a group of Users through the same shift at a set interval.
Schedules are used by Escalation Policies as an escalation target for a given Escalation Rule.
PagerDutyService ¤
Bases: Model
A Service represents an entity you monitor (such as a web Service, email Service, or database Service.) It is a container for related Incidents that associates them with Escalation Policies. A Service is the focal point for Incident management; Services specify the configuration for the behavior of Incidents triggered on them. This behavior includes specifying urgency and performing automated actions based on time of day, Incident duration, and other factors.
PagerDutyUserManager ¤
Bases: Manager['PagerDutyUser']
get_current_on_call_users_l1
staticmethod
¤
Returns the list of oncall first responders in each escalation policy. Only the lowest escalation level user is returned per Escalation Policy.
These users have their PagerDutyUser associated.
Source code in src/firefighter/pagerduty/models.py
upsert_by_pagerduty_id
staticmethod
¤
Returns a User from PagerDuty info. It will update a PagerDutyUser and its associated User if the name, phone, PagerDuty team changes.
Source code in src/firefighter/pagerduty/models.py
service ¤
tasks ¤
PagerDuty Celery tasks.
fetch_oncall ¤
fetch_oncalls ¤
Celery task to fetch PagerDuty oncalls and save them in the database. Will try to update services, users, schedules and escalation policies if needed.
Source code in src/firefighter/pagerduty/tasks/fetch_oncall.py
fetch_services ¤
fetch_services ¤
Celery task to fetch PagerDuty services and save them in the database.
Source code in src/firefighter/pagerduty/tasks/fetch_services.py
fetch_users ¤
fetch_users ¤
Celery task to fetch PagerDuty users and save them in the database.
Source code in src/firefighter/pagerduty/tasks/fetch_users.py
trigger_oncall ¤
trigger_oncall ¤
trigger_oncall(
oncall_service: PagerDutyService,
title: str,
details: str,
incident_key: str,
conference_url: str,
incident_id: int | None = None,
triggered_by: User | None = None,
) -> PagerDutyIncident
Celery task to trigger an on-call in PagerDuty, from a FireFighter incident.
XXX Trigger from PD user if it exists, instead of admin. XXX Should be a service ID instead of a service object.
Source code in src/firefighter/pagerduty/tasks/trigger_oncall.py
urls ¤
views ¤
oncall_list ¤
OncallListView ¤
Bases: ListView[PagerDutyOncall]
get_context_data ¤
No *args to pass.