PagerDuty's Paige can close incidents alone: set the limits first

What PagerDuty released

PagerDuty made Paige, its site reliability engineering agent, generally available on 3 November and renamed its Operations Cloud product the PD Reliability Platform. Paige investigates incidents and can carry out the fix. A team can add Paige to an escalation policy as a "virtual responder", which means a lower-priority incident may be resolved before anyone gets paged. SiliconANGLE reports that permissions are set team by team and that Paige acts alone only in low-risk scenarios a team has explicitly authorised. DevOps.com describes the same split, with a human-approval mode for teams that want Paige limited to triage.

The local angle came a day later, when IT Brief reported that PD Labs, an AI innovation centre, had opened for customers in Australia and New Zealand. PagerDuty's own release describes PD Labs as a programme built with design partners and doesn't mention either country, so NZ buyers should ask what regional access covers. PagerDuty's Ingram Micro distribution deal, announced in June, also names Australia only.

Freshworks is working on the same problem from the service desk side. On 28 October it announced the purchase of Robusta, whose AI agents investigate disruptions and recommend fixes for engineers to approve before production is touched. Freshworks plans to bring Robusta into Freshservice, although IT Brief notes that no integration timetable was given. Two vendors moving within a week shows that AI incident investigation is heading into mainstream service management tools.

Why an automated fix needs change control

An agent that restarts a service at 3am has changed a production system, and most service desk controls assume a person made that change. ITIL 4 already has a useful category for the problem: the standard change, which is low risk, pre-authorised and follows a documented procedure. Paige's autonomous scenarios apply the same idea to software. An organisation without a maintained list of standard changes has no sound basis for telling an agent what it may do alone.

Buyers should also read the evidence behind the marketing. PagerDuty says Paige beat leading AI coding agents at diagnosing simulated incidents. The benchmark report is more candid than that headline: PagerDuty built and ran the test, acknowledges the conflict of interest, and gave each agent one trial across 17 scenarios. The report says the work focused on triage and diagnosis, and the agents didn't carry out any remediation. The published results therefore offer some support for Paige's diagnostic ability and no test of Paige fixing a live system unaided. PagerDuty's stated plan is to add remediation assessment later, and buyers should hold autonomous mode to that standard.

The cost of getting incidents wrong is real, though the best local figures come from vendors. PagerDuty's 2025 Australian research, based on a survey of more than 1,000 Australians, puts annual losses from service disruptions at 73 million hours and AUD 5.3 billion, with 72% saying they'd walk away after one poor experience. Those numbers come from a company selling incident software, so they're best read as a rough guide to how customers react.

What it means for NZ businesses

Organisations that don't use PagerDuty should still prepare, because the Robusta deal shows similar capabilities moving into general service desk products. The groundwork is the same whichever platform you run, and NZ results suggest many organisations have gaps. In Datacom's survey of 155 NZ leaders, 85% were confident of keeping critical services running through a disruption, yet only 39% had tested restoring critical systems and data in the past six months, and 13% had never tested recovery. An agent acting on untested runbooks will repeat their flaws faster than a person would.

Memory creates a quieter risk. Paige builds a shared memory from each resolved incident, so a workaround that hid a fault can become a lesson the agent applies again. Many service desks already close tickets with thin resolution notes, and those notes are now potential training material for an automated responder.

Regulated firms have a further reason to take care. The FMA's standard condition, in force since 1 July 2024, requires covered licence holders to notify the FMA no later than 72 hours after determining an event is a material incident. NSP reports that the FMA's current consultation would move financial advice providers from ten working days to the same 72-hour window. We couldn't confirm that detail on the FMA's summary page, but the page does show submissions closing on 11 December 2026, and affected firms should read the consultation paper itself. An incident an agent resolves quietly could still meet the materiality test, and the person who makes that call needs to see it.

Pricing deserves scrutiny too. The PD Reliability Platform has a fee based on operational scale, covering an allotment of events, AI and automation actions, and seats, with credits sold for extra use. Customers buying before 15 January 2027 get additional AI Actions capacity free for the first year, so ask for the second-year cost before signing. Noisy monitoring could burn through an event allowance quickly, which makes alert tuning a sensible job to finish before any usage-priced tool goes live.

Practical next steps

• List the incident types you'd let an agent fix alone, starting from your existing standard changes. Anything without a tested rollback stays on human approval.
• Record every agent action as a change, including the evidence, the confidence level and the rule or person that authorised it. SiliconANGLE reports that Paige's recommendations include evidence and a confidence level, so ask any vendor for the same.
• Run new agents in approval mode for a fixed trial, then compare their recommendations with what your engineers did before widening permissions.
• Name an owner for agent memory, with a way to correct or remove bad lessons. Tighten resolution notes now, because they may feed future automation.
• Route auto-resolved incidents on critical systems to the person responsible for regulatory and privacy decisions, so automation doesn't bypass a notification judgement.
• Test a restore of your most critical system this quarter and update the runbook with what you find before any agent relies on it.
• Ask vendors where incident data and agent memory are stored, how long they're retained, who supports NZ customers, and what happens to pricing after any first-year offer.