PagerDuty contract cancellation: Exit terms, data portability & switching timeline

TL;DR: PagerDuty contracts auto-renew for a full additional term unless you send written notice to PagerDuty's renewals address at least 30 days before your renewal date. Export your incident history via the REST API and CSV before you cancel, because canceling the account permanently deletes it and all related data. Removing users in the PagerDuty UI does not reduce your contracted seat count, so plan the exit around your contract end date, not your active user list. The incident.io PagerDuty Rescue Program, launched May 2026, covers up to 12 months of incident.io at no cost on a multi-year deal, which removes the double-billing overlap during the transition.

Deleting users in PagerDuty does not cancel your contract. Many finance teams discover this only after months of paying for seats that never reduced the monthly invoice. PagerDuty billing tracks the highest seat count your account has reached rather than your current active users, and the contract itself renews on its own unless someone sends notice in time.

This guide covers the steps to cancel a PagerDuty contract safely, export your historical incident data, and migrate your on-call schedules to a Slack-native platform without a service gap. The contract terms described below come from PagerDuty's published Terms of Service and are summarized here for orientation only. They are not legal advice, and your signed order form governs. Review it, and consult legal counsel, before you act.

Understanding key legal pitfalls in PagerDuty agreements

PagerDuty's standard Terms of Service contain several provisions that catch engineering and finance teams off guard. Understanding these before you act determines whether you exit cleanly or owe a significant unexpected balance.

Finding key dates in your PagerDuty contract

Your contract start date, end date, and cancellation window live in your signed order form, not the PagerDuty web UI. Pull the original purchase order or your signed agreement from your finance team. The cancellation window, 30 days before the renewal date, runs from the contract end date on that document, not from when you received your last invoice.

Managing PagerDuty renewal deadlines

PagerDuty contracts auto-renew at the end of a contracted term for an additional term of the same length. Automatic renewals carry a twelve-month minimum unless you are a month-to-month customer who bought through the self-serve portal. As with most enterprise SaaS agreements, missing that window commits you automatically. Many teams only realize they have missed it when the renewal invoice arrives and the next contract year has already started.

Set a calendar reminder 90 days before your renewal date. That covers the 30-day notice window plus a 30-day parallel run, and still leaves time to evaluate alternatives and negotiate.

Time your notice precisely. Send written notice to renewals@pagerduty.com at least 31 days before your renewal date and get a confirmed-receipt record. Sending at exactly 30 days risks a disputed timestamp; 31 days gives you a clean margin. This is the only standard-agreement path to exiting at the term boundary without owing the remaining balance.

Renewal is also when pricing moves. At 500-plus users on multi-year terms with module commitments, third-party benchmarking data puts typical discounts at 33 to 40% off list. Smaller teams have less room, but the window is the same.

Sending required notice for PagerDuty cancellation

PagerDuty's standard Terms of Service do not include a general termination-for-convenience right. Each order form is non-cancellable and non-refundable per the agreement. Two exit paths exist under the standard agreement, and your signed order form may add a third: check it for any negotiated early-exit clause.

Send that notice to PagerDuty's renewals address, renewals@pagerduty.com, which is the channel the Terms of Service specify, and copy your account manager. An email to your account manager alone is not the contractual channel. Get written confirmation of receipt with a timestamped record, and check your own order form in case it names a different notice period.

Two exit scenarios define how termination works in practice:

• Non-renewal (standard exit): Send written notice to renewals@pagerduty.com at least 30 days before your renewal date. Orders are non-cancellable mid-term; this path lets you exit at the term boundary without owing the remaining balance. Missing the window triggers an automatic renewal for an additional term of the same length.
• Termination for cause: Either party can terminate with written notice if a material breach, such as a sustained SLA failure, remains uncured after a 30-day cure period. If you are the party terminating for cause, PagerDuty refunds prepaid fees covering the remainder of the subscription term.

Outstanding fees fall due on termination, and provisions covering Confidentiality, Proprietary Rights, Indemnification, and Limitation of Liability stay in force afterward.

Avoiding PagerDuty exit fees and penalties

Three things drive the cost of a mid-term exit: the termination terms, your billed seat count, and what you can offset against it.

Knowing when early termination fees apply

PagerDuty's standard agreement makes each order non-cancellable and non-refundable. There is no general right to exit mid-term for convenience under the standard ToS. If you are mid-term and cannot establish grounds for termination for cause, your practical options are to run out the term with proper non-renewal notice or negotiate directly with PagerDuty. Check your signed order form: some negotiated agreements include an explicit early-exit clause that changes this analysis. If yours does not, the remaining term commitment stands.

Breaking down PagerDuty exit costs

List pricing runs at roughly $21/user/month on PagerDuty Professional and $41/user/month on Business, as of this writing. If you have 20 seats on a $41/user/month contract with 10 months remaining:

• 20 seats × $41 × 10 months = $8,200 potentially due immediately.
• Convenience cancellations carry no prorated refund for unused time.

A critical distinction on seat counts: removing or deleting a user in the PagerDuty UI does not by itself lower your invoice. Billing tracks the highest seat count your account has reached during the period, not your current active user count. Deactivating a user suspends their access while retaining their profile and historical data, but lowering the billed count is a separate action the account owner has to take, and on an annual contract that reduction generally lands at renewal.

Under the standard non-cancellable agreement, if you are mid-term without grounds for termination for cause, you remain liable for the remaining commitment regardless of usage. The $8,200 figure illustrates that exposure. It is not a fee you trigger by canceling; it is the obligation that already exists in the contract.

Reducing PagerDuty exit costs

If you are mid-term and your signed order form includes a negotiated exit clause or you are evaluating options before committing to the next renewal. Two strategies reduce your exposure:

1. Negotiate at renewal: If you cannot cancel immediately, use the upcoming renewal as leverage to reduce seat counts, negotiate a shorter term, or extract a service credit.
2. Use the incident.io PagerDuty Rescue Program: Launched May 2026, the Rescue Program covers up to 12 months of incident.io at no cost on a multi-year deal. This offsets the double-billing period during migration and is built for teams stuck paying for PagerDuty through the end of their term.

Exporting your incident history safely

Export everything before you cancel your PagerDuty account. Canceling permanently deletes the account and all related data, so waiting until after termination means losing your incident history with no recovery path.

The export mechanics below are hands-on work. If you are running the migration rather than writing the export script, hand this section to whoever owns the export.

Choosing PagerDuty export formats

Two methods cover most export needs:

• CSV export via the UI: Suitable for quick spreadsheet analysis. Use the incidents list view, apply your date filters, and export. This works for smaller datasets but loses structured metadata that is useful for future analysis.
• JSON via the REST API: Required for complete historical preservation. The API returns structured incident objects with all fields, responders, timestamps, and linked services intact. Use this format if you plan to import history into a new platform.

Moving on-call setups to new tools

Document why your escalation policies and rotation schedules are structured the way they are. A structured export captures the data but not the reasoning, and the reasoning is what you need to rebuild the logic accurately or to decide it is worth changing.

You do not need to inventory the configuration by hand. incident.io runs a pre-migration scan: you supply a read-only PagerDuty API key, and it reads every service, escalation policy, and schedule configuration in your account, then returns a complexity score before you commit to anything.

From there, incident.io imports schedules and escalation policies directly from PagerDuty, in bulk, so nobody spends a week retyping rotations into a new tool.

Exporting incident records

Use the PagerDuty List Incidents API endpoint to pull your full incident history. Set limit=100 explicitly, since the default page size is 25 and 100 is the maximum. The since and until parameters define your date range, limit sets records per page, and offset increments by 100 for each subsequent page.

The sum of limit and offset must stay below 10,000 on a single query, so split large exports by date range rather than paginating past the cap.

Extracting your PagerDuty logs

The API pulls the detailed activity timeline for each incident via the log entries endpoint. Consult PagerDuty's API reference for the current optional parameters on the endpoint, which control how much context each entry carries.

Once you submit the account cancellation request, the associated data is gone. incident.io publishes a sample import script for loading exported PagerDuty incidents into incident.io, and documents the broader process for bringing historical incidents onto the platform so your insights cover more than the incidents you declare from now on.

Planning your PagerDuty migration window

A structured timeline prevents three common migration failures: missed data exports, routing gaps during cutover, and double-billing that runs past the PagerDuty term end.

The 30-day plan below fits teams with straightforward escalation policies. Mid-size teams should expect several weeks including parallel running and pilot validation, and enterprise teams with complex event orchestration should plan for weeks to a couple of months. Size the window against your own configuration before you commit to a cancellation date.

Week 1-2: Planning the PagerDuty exit

• Run the pre-migration scan. Supply a read-only PagerDuty API key and let incident.io map every service, escalation policy, and schedule, then review the complexity score it returns.
• Pull your contract end date and calculate the 30-day cancellation notice deadline.
• Send formal written cancellation notice to renewals@pagerduty.com, copying your account manager and the billing contact named in your contract. Get written confirmation of receipt.
• Begin the REST API data export covering incidents, log entries, schedules, and users.
• Book a demo and ask about the Rescue Program if you are mid-term on a PagerDuty contract.

Week 2-3: Verifying migration integrity

• Configure the incident.io integration and run the PagerDuty importer to import escalation policies and rotation schedules in one bulk pass.
• Re-point monitoring tool integrations to incident.io using the Datadog monitors migration guide.
• Import your user directory and verify on-call schedule accuracy against your exported PagerDuty schedules.
• Run test incidents using /inc commands in Slack to validate routing and notification behavior.

Week 3-4: Completing the PagerDuty migration

• Activate a parallel on-call rotation where both PagerDuty and incident.io receive alerts simultaneously.
• Run the parallel period until engineers handle a real incident in incident.io without reverting to PagerDuty.
• Complete the final data export pass and verify exported record counts against your incident list to confirm completeness.
• Verify your status page, Jira or Linear task creation, and post-mortem auto-drafting work end to end before canceling your PagerDuty account.

Managing dual incident platforms during migration

Running two platforms simultaneously is the safest way to migrate without a reliability gap, but it requires deliberate configuration and two things settled in advance.

Mitigating migration downtime risks

Configure dual-routing at the monitoring tool level by setting Datadog or Prometheus to deliver alerts to both your PagerDuty service endpoints and your new incident.io alert sources. A routing misconfiguration in incident.io during the test period then drops no alerts, because PagerDuty remains the active safety net. incident.io's migration guide describes running both systems simultaneously as the key risk-reduction mechanism, and it matches the broader engineering consensus that a parallel run is the most effective way to de-risk a phased migration.

Two things to settle before the parallel period starts. Engineers will receive notifications from both systems, which feels noisy for the first few incidents. More importantly, decide which system is authoritative for acknowledgment and tell the rotation. Otherwise, two responders can each assume the other has it.

Setting the parallel run period

Two weeks is a reasonable floor for a PagerDuty parallel run. The goal is not a day count, it is a confidence threshold: get your on-call engineers through at least one real incident in incident.io while PagerDuty still routes as backup. Once engineers handle a live incident via /inc commands in Slack without reverting to PagerDuty, you can deactivate PagerDuty routing.

Scale matters less than configuration complexity here. Zendesk migrated 1,200 users, 150 teams, and 5,000 monitors with a core team of two and no major issues.

Minimizing double billing

The most direct solution is the PagerDuty Rescue Program: teams mid-term on a PagerDuty contract receive up to 12 months of incident.io at no cost on a multi-year deal. This removes the budget pressure of running both tools at once.

For a direct comparison of the contract and migration dimensions that matter most during a switchover:

Timing your PagerDuty exit and offboarding

Your exit hinges on two things: hitting the renewal or expiry deadline, and deprovisioning cleanly once migration is done.

Acting before renewal or expiry

The renewal date is the most reliable forcing function. The standard PagerDuty agreement makes orders non-cancellable mid-term. Missing the 30-day non-renewal notice window commits you to a full additional term and the fees that come with it, and forfeits your best negotiating leverage.

Teams that act 90 days out can evaluate alternatives, run a parallel test, and send notice inside the window. Build the migration timeline backward from that date, account for the parallel run period, and leave time for verification. That buffer is what stops you rushing the final export or discovering missing integration configurations during deactivation.

Offboarding PagerDuty data safely

Full deprovisioning after migration requires more than deactivating users. Work through this before canceling:

• Reassign or resolve any open incidents assigned to departing users.
• Revoke active API keys to prevent unauthorized access.
• Delete webhook integrations pointing to PagerDuty endpoints.
• Remove the PagerDuty app from your Slack workspace.
• Disable SSO connections tied to PagerDuty.
• Confirm no active monitoring tool webhooks still point to PagerDuty service URLs.

Preparing to cancel PagerDuty services

Your Slack setup needs the most careful handling during cutover, because the difference between the two platforms is where coordination happens after the page. incident.io's Slack-native architecture runs the entire incident lifecycle inside Slack: channel creation, on-call paging, timeline capture, and resolution all happen through /inc commands without leaving chat.

"I replaced PagerDuty with incident.io to manage scale and complexity, providing a single source of truth and automating incident handling. The Catalog centralizes our R&D info, and workflows..." - Verified user on G2

Installing incident.io across a Slack Enterprise Grid, so a single account serves multiple workspaces, is available on the Enterprise plan. Separately, if your own organization is migrating to Enterprise Grid mid-transition, incident.io handles that automatically by pausing user syncing and exchanging user IDs as they change.

Investigations, incident.io's AI SRE product, connects your telemetry, code changes, and incident history to identify root causes and suggest fixes that a human reviews before merging. incident.io's own framing is that Investigations gets teams from alert to resolution an order of magnitude faster, which means the coordination overhead PagerDuty leaves in your hands gets handled in Slack instead. Fin migrated off PagerDuty and Atlassian Status Page onto incident.io in a matter of weeks, reporting faster mean time to resolution (MTTR) and less cognitive overhead as the measurable outcome.

Getting the exit terms right, exporting your data cleanly, and running a parallel migration all lead to the same decision point: where your team coordinates incidents next. The Pro plan at $45/user/month with on-call ($25 base + $20 on-call add-on) includes unlimited workflows, custom incident types, Microsoft Teams support, AI-powered post-mortem generation, and escalation paths. See the full pricing breakdown for every tier and add-on.

Book a demo of incident.io to walk through Rescue Program terms, see the migration tooling run against your own configuration, and handle a live incident in Slack before you finalize your cancellation timeline with PagerDuty.

Key terms glossary

Termination for convenience: An early-exit right that some SaaS agreements include, allowing a customer to exit mid-term for any reason with written notice, typically making remaining fees immediately due.

Termination for cause: Termination triggered by a material breach, such as a sustained SLA failure, after a 30-day written cure period expires without resolution. Unlike termination for convenience, terminating for cause entitles you to a refund of prepaid fees covering the remainder of the term.

Dual-routing: A migration technique where monitoring alerts go to two incident management platforms at once, so the new system can be validated under real conditions without risking dropped alerts during cutover.

High-water mark billing: A billing model where the invoice tracks the highest seat count reached during a billing period rather than current active users, meaning user deletions do not lower the bill until the count is separately reduced.