Connect PagerDuty
Connect PagerDuty so Adduce reads the incidents your team declared, how long each one lasted, and how many people it pulled in.
Adduce reads the incidents your team declared in PagerDuty — what was hit, how long it lasted and how many people it pulled in — and keeps them beside what your customers said at the time.
Beta
This connector works, but it has not been proven against a real customer account yet, so Adduce badges it Beta wherever it appears. Tell us at hello@adducehq.com if what you see does not match this page.
Before you begin
- Role: project Editor or Lead. A workspace Admin is a lead on every project.
- In PagerDuty: an account where you can create an API key.
- To hand: a read-only API key, and the service IDs if you want to sync only some services.
- Time: five minutes.
What Adduce reads
| Surface | What it becomes |
|---|---|
| Incidents | One piece of evidence per incident: the service, the title, how long it ran, the responder and alert counts |
A high-urgency incident becomes a pain point; a low-urgency one becomes an observation. An incident that is still open says so, and grows more serious on each sync until it is resolved. A resolved incident keeps its evidence — the outage happened.
Permissions the key needs
Create the key under Integrations → API Access Keys and tick read-only. A read-only key can list incidents and the services, responders and priorities attached to them, which is everything Adduce reads. Nothing is ever written back, and no key that can write is asked for.
A key restricted to one team can be refused access to incidents even though the key itself is valid. The connection test tells those two failures apart.
Steps
In PagerDuty, open Integrations → API Access Keys, choose Create New API Key, and tick read-only. Copy the key.
In Adduce, open the project, choose Sources, then Add source, and choose the PagerDuty tile.
On Connection details, name the source and paste the key. Set Service region to EU only if your account was provisioned there.
Leave Services empty to read every service, or paste a comma-separated list of service IDs — they look like PIJ90N7 — to read only those.
Choose Urgency. High urgency only is the default and is usually what you want; low-urgency incidents are mostly noise.
Choose Continue. Adduce asks PagerDuty for one incident using your key, which proves the key, the region and that it can see incidents at all.
Back on Sources, the new row shows Connected, and a signal count once the first sync has run.
First sync and cadence
The first sync reads ninety days of incidents. After that each run re-reads the last thirty days as well as anything new, because PagerDuty filters incidents by when they were created and not by when they changed — an incident opened last week and resolved today would otherwise stay frozen as "still open". Adduce syncs once a day at 03:00 UTC, and Sync now runs one immediately.
If every service ID you entered is rejected, the sync fails rather than quietly reading your whole account.
Disconnect or replace credentials
Delete the source from its page and type its name to confirm. Deleting removes the evidence it produced. To rotate the key, or to change which services are read, delete the source and add it again; the next sync backfills ninety days.
If it did not work
Why was the API key rejected?
PagerDuty did not recognise it. Keys are shown once, at creation, so a key copied part-way is the usual cause. Create a new read-only key and add the source again.
Why does it say the key cannot see incidents?
The key is real but scoped away from what Adduce reads — usually a key restricted to one team, or one created without incident read access. Create the key at the account level with read-only ticked.
Why are there fewer incidents than I expected?
Either the urgency filter is doing its job — High urgency only is the default — or the Services box lists fewer services than you have. Neither can be edited after the source exists: delete the source and add it again with the choices you want.