Import your PagerDuty schedules in one click.
Rotations without the enterprise maze. Bring your schedules and escalation policies across, keep the Events v2 payloads your tools already send, and pay for responders, never for the people who just need to watch.
Schedules, escalation policies and the next 30 days of overrides. Teammates are matched by email; your read-only API key is used once and never stored.
- 0 min Page primary · push
- 5 min Page secondary · push + email
- 15 min Notify #incidents and engineering lead
Your on-call setup, mapped one to one.
| In PagerDuty | In Pulseback |
|---|---|
| Schedules | Schedules: rotations with a handoff day and time, restrictions and overrides Swaps from the mobile app. Team and up. |
| Escalation policies | Escalation policies: steps with delays, repeats until acknowledged |
| Events API v2 integrations | Events API integrations: same payload, new URL and routing key |
| Email integrations | Email integrations at <key>@alerts.pulseback.io |
| Users and notification rules | Responders with their own notification rules: push and email |
| People who only follow incidents | Viewers: free and unlimited on every plan |
Switch over without a gap in coverage.
- 01 Invite your responders Create a workspace and invite the people who take shifts. Everyone else can join as a free viewer.
- 02 Import schedules In On-call → Import from PagerDuty, paste a read-only API key. Schedules, escalation policies and upcoming overrides come across, and anyone not yet invited is listed.
- 03 Check the rotations Compare who’s on call this week in both tools before anything pages.
- 04 Repoint your alerts Change the Events API URL to
https://app.pulseback.io/api/v1/eventsand swap in a Pulseback routing key. The payload stays the same. - 05 Send a test page Install the mobile app, then send yourself a test page from your account to check every channel.
Keep the alerts you already send.
Pulseback’s Events API accepts PagerDuty Events v2 payloads. Change the URL and the routing key in your alerting tool, CI or scripts; the rest of the request stays as it is.
-
trigger,acknowledgeandresolveactions - Dedup keys group repeats into one incident
-
202with the dedup key and the incident id
# Same body as Events v2. Only the URL and routing key change. curl -X POST https://app.pulseback.io/api/v1/events \ -H "Content-Type: application/json" \ -d '{ "routing_key": "<your integration key>", "event_action": "trigger", "dedup_key": "db-replica-lag", "payload": { "summary": "Replica lag above 30s", "source": "db-2", "severity": "critical" } }'
One bill. One alert path. One timeline.
The check that fails is the incident that pages is the update your customers see. No glue code in between.
-
Monitoring included
HTTP, TCP, DNS, SSL, heartbeat and cron checks from several regions, confirmed before they page.
-
Status pages included
Customer-facing pages in sync with your monitors, updated from the incident.
-
Likely cause
Recent deploys are ranked against the failure, so the incident opens with a suspect.
-
Summaries and postmortems
“What we know” and postmortem drafts written from the timeline (Starter and up).
-
An independent alert path
Escalation runs apart from the dashboard and keeps paging through our own outage.
-
Priced on what you monitor
Pay for monitors and responders. Viewers never cost a seat.
Moving from PagerDuty
Is the Events API really compatible?
It takes the Events v2 body: routing_key, event_action (trigger, acknowledge, resolve), dedup_key, payload (summary, source, severity, component, group, class, custom_details) and links. Severities map critical → SEV-1, error → SEV-2, warning → SEV-3, info → SEV-4. Fields Pulseback doesn’t use are ignored. See the Events API docs.
Do alerts with the same dedup key page twice?
No. Events with the dedup key of an open incident are grouped into it, and resolve with that key closes it.
Can people acknowledge without opening the app?
Yes: the Acknowledge button on the push notification, pressing 1 on a call, replying to a text, or replying ack to an alert email.
What if Pulseback itself is having a bad day?
Escalation for an open incident runs on its own durable scheduler with everything it needs, separate from the dashboard and API, so pages keep going out. Our own status is at the link in the footer.
PagerDuty is a trademark of its owner. Pulseback isn’t affiliated with or endorsed by PagerDuty. This page describes how Pulseback works and how to move over; check PagerDuty’s own documentation for its current features and pricing.
Get paged when Pulseback launches.
Pulseback is almost ready. Join the waitlist and we’ll email you the day it opens, Free plan and all.
Join the waitlist