On-call & escalation

On-call in Pulseback has three parts: schedules say who is on call, escalation policies say who gets paged and when, and each person’s notification rules say how to reach them.

Schedules, overrides, swaps and multi-step escalation policies are on plans with rotations (see Pricing). On other plans, an escalation policy has a single step that pages people directly.

Schedules

A schedule is one rotation of people in a time zone.

The On-call page shows each schedule’s next weeks, who’s on call now and the upcoming handoffs. In the mobile app, My on-call lists your shifts for the next 30 days.

Overrides

An override puts someone else on call for a stretch of time, from an hour to a holiday. It wins over the rotation and shows dashed on the schedule.

Swaps

Ask a teammate, or anyone in the rotation, to cover a shift from the app or the dashboard. They get a low-urgency notification; accepting creates the override for you. You can cancel a request until it’s answered.

Importing from PagerDuty

In On-call → Import from PagerDuty (admins, Team plan and up), paste a read-only REST API key (PagerDuty → Integrations → API Access Keys). Pulseback imports each schedule layer as a rotation (daily, weekly or custom, with handoff times in the schedule’s time zone), restrictions that fit a daily window, the next 30 days of overrides, and escalation policies with their delays and repeats. People are matched to members by email; anyone who isn’t a member yet is listed so you can invite them and import again. The key is used once and never stored, and anything already imported is skipped by name.

Over the API: POST /api/workspaces/:wid/on-call/import with { "source": "pagerduty", "apiKey": "…" }.

Escalation policies

A policy is a list of steps. When an incident opens, step 1 fires immediately (or after its delay), then each later step fires after its own delay unless someone has acknowledged.

A typical policy:

1. 0 min — Platform primary schedule
2. 5 min — Platform secondary schedule
3. 15 min — #incidents in Slack and the engineering lead

Acknowledging an incident cancels every step and repeat still queued. Escalation for each incident runs on its own durable scheduler, separate from the dashboard and API, so it keeps going even if our app has a bad day. Every delivery has an idempotency key, so a retried step can’t page the same person twice.

Notification rules

Each responder decides how they’re reached when a step pages them, in Account → Notification rules:

Each rule has a delay from 0 to 60 minutes, so you can push right away, push again two minutes later and email after five. New accounts start with push at 0 minutes and email at 1 minute. Rules stop firing as soon as anyone acknowledges, and if your phone can’t be reached by push, Pulseback emails you instead. SMS and phone calls aren’t available yet.

Use Send me a test page in your account (or the app’s On-call tab) to check that pages reach you.

Incidents

Where incidents come from

• A monitor going down (Monitors)
• The Events API and email integrations
• Someone creating one by hand, with or without paging

Lifecycle

triggered → acknowledged → identified → monitoring → resolved. A resolved incident can be reopened.

• Acknowledge to say you’re on it. Escalation stops.
• Escalate to page the next step now, or reassign to a person or schedule.
• Resolve when it’s over. Monitor incidents resolve themselves when every linked monitor is back up.

Grouping

Alerts with the same dedup key join the open incident instead of paging again. Monitors that fail in the same environment within five minutes of an open incident are attached to it as related alerts.

On the Business plan, workflows run first: ordered rules that can set the severity, pick the escalation policy, open an incident quietly or suppress an alert, based on its source, payload, monitor tags or the time of day.

The incident view

Owner and responders, the timeline of every alert, page, acknowledgement and note, the response-time chart around the trigger with deploy markers, and the likely cause. On plans with AI, Pulseback drafts a “What we know” summary and, afterwards, a postmortem from the timeline.

From the incident you can post to your status pages; the update lands on the timeline too.

Roles

Responders and admins count toward your plan’s responder limit.