What are you trying to do?

Review the team's on-call schedule and rotation. Use an override for a short-term change and adjust the rotation for a lasting one — do not repoint routing or escalation at a person.

Start with routing and team ownership before modifying individual notification behaviour. If the wrong team owns the signal, no notification change will fix it.

Review the integration, routing logic, responders and service ownership. Confirm the intended team is still the correct ownership boundary for that signal.

Trace the path in order and identify the first step where the expected flow broke.

Work from the source inward. Most volume problems are solved at the integration or policy layer, not by adding automation.

Decide the operational design before configuring anything.

• What events should become alerts?
• Which team owns them?
• What priority should they receive?
• Should they be grouped?
• What escalation path applies?
• Who owns this integration operationally?

Define the capability and its ownership before creating the record.

• What capability does the service represent?
• Who owns it?
• Which team supports it?
• Which incidents should be associated with it?
• Does it need user-facing service offerings?

Ask first: "Is the response behaviour truly different, or can an existing escalation be reused?" Most new policies are variations of a pattern that already exists.