How to use a Righthand with PagerDuty

Quick answer

Use Righthand to prepare a PagerDuty open-incident briefing with ownership evidence. Acknowledgment and resolution have different meanings and should remain separate.

Start with a reviewable deliverable, keeping PagerDuty as the accepted home for its records. This guide uses an explicitly approved snapshot or browser read; it does not assume that every provider API action is exposed by your Righthand connection.

Evidence and access

PagerDuty documents incident states and acknowledgment operations. See the official PagerDuty reference. Provider capabilities and Righthand's available tools are separate checks.

Use the approved service's incident export and responder timeline with incident IDs, escalation policy, status transitions, and acceptance evidence. Verify the required tools and owner-approved scope through Righthand integrations; use the supplied packet when a native read is unavailable.

Define the objects and authority

Include these fields in the working input: incident ID, service, urgency, triggered time, acknowledged state, assignee, resolution evidence. These are the requested review columns, not a promise that every provider endpoint returns them under those exact names.

Acknowledged means someone accepted the response, not that service is restored. Paging, reassignment, and resolution need on-call authority.

Illustrative first-run brief

Use the owner-provided PagerDuty snapshot or approved read-only view. Review the supplied current incident list. Separate unacknowledged work, accepted response, and resolved records; identify missing follow-up checks without taking actions. Run once for the agreed sample, using America/Los_Angeles for the review deadline and preserving source timestamps separately. Return the draft in this conversation by Friday at 3 PM Pacific for the on-call coordinator to review. Include source references and missing fields. Do not write records, spend money, change permissions, or send external messages. Stop and report an unavailable source rather than substituting another account.

Expected result and verification

An acknowledged incident still needing recovery evidence remains open. A resolved record can require a separate post-incident task.

Match one incident ID and assignee to its latest status and accepted response notes. Record the source cutoff, applied filters, and items excluded from the sample. The reviewer should be able to follow each consequential finding back to an original object. A well-written summary is not evidence that a proposed action happened. If a later write is authorized, verify its specific result separately before changing the task's status.

Illustrative input and draft output

These synthetic entries show the requested review, not live account results or a provider field schema.

Common failure and recovery

An older alert email may not show a reassignment. Refresh the incident object rather than paging the outdated owner.

When a resolved incident lacks customer-path proof, report that evidence gap and ask the incident owner for the specific recovery check.

FAQ

What should the reviewer verify first?

Verify incident ID, service, trigger, acknowledgment, resolution time, and responder ownership. These events describe response progress rather than interchangeable completion states.

How should a repeat run be scoped?

Preserve incident chronology and service scope on each review. Track new incidents separately and verify the owner-defined customer result before reporting closure.

For connection and permission details, use Righthand Docs. Review Pricing alongside any separate provider charges before expanding the workflow.