Phoenix Alerts
Phoenix Alerts is the built-in paging system in Phoenix Incidents. Instead of connecting an external tool like PagerDuty, Opsgenie, or VictorOps, you can run on-call scheduling, alerting, and escalation directly inside Phoenix.
Phoenix Alerts needs the Advanced edition of Phoenix Incidents. Free, which does not include paging, is a separate app from Phoenix Incidents, with its own Marketplace listing. If your site is on the Standard edition, the Phoenix Alerts pages and the admin Paging page show a message that Phoenix Alerts needs Advanced, with a link to view editions on the Atlassian Marketplace and an email link to [email protected]. You choose or change your edition on the Marketplace listing or in your Atlassian billing admin.
🧩 How it fits together
A quick tour of the building blocks:
Teams – the people who respond to alerts. A team owns its escalation policies and on-call schedule.
Services – the systems you monitor. Each service belongs to one team and is the target that alerts are routed to.
Escalation Policies – the steps that decide who gets paged, and when, until someone responds. Every team gets a default policy automatically.
On-Call Schedules – the rotation that decides who is on call at any given time, with support for overrides.
Users – everyone who can receive a page or manage Phoenix Alerts. Each user has a role and verified contact methods.
API Keys – the credentials your monitoring tools use to send alerts into Phoenix Alerts.
🚀 Getting set up
When you install Phoenix Incidents, your Phoenix Alerts account is created automatically for your site, and the person who installs the app becomes the first Owner.
From there, work through the setup checklist on the Configuration page:
Add your teams.
Add your services and assign each one to a team.
Add your users and verify their contact methods.
Create an API key to connect your alert sources (optional).
The checklist disappears once everything is in place.
🔑 Access and roles
Owner – full access. Owners manage teams, services, policies, users, and API keys, and set the default paging target.
Member – can acknowledge and resolve alerts and view schedules, but cannot change configuration.
If you are a Jira admin without a Phoenix Alerts account yet, open the Alerts page and you'll be prompted to create your own. If you are not an admin, you'll see a list of your Owners. Ask one of them to add you.
📟 Choosing Phoenix Alerts as your paging provider
Phoenix Alerts is one of four paging providers, alongside PagerDuty, Opsgenie, and VictorOps (Splunk On-Call). You pick your provider in the Paging settings. Once Phoenix Alerts is your provider, you map each Impacted Product to a Phoenix Alerts service or team, the same way you would map to an external service or policy.
Already paging with PagerDuty, Opsgenie or VictorOps? You can send every page to Phoenix Alerts as well while you move over. On the Paging page, tick Also send pages to Phoenix Alerts. Your current pager stays in charge of the incident, and Phoenix Alerts pages your on-call too. Pages go to your Phoenix Alerts default paging target, so your product mappings do not need to change.
For how products map to paging targets, and for the steps to run both pagers at once, see Configure Paging.