Reference · built on requestOperator by FibricIT & reliability

On-call Handoff

Drafts the shift handoff from the pager schedule, open incidents, muted monitors, and open tickets for the outgoing engineer to approve.

Request accessPricing ↗

About

The handoff note is written at the end of a long shift, from memory, if at all. On-call Handoff reads the PagerDuty schedule to know when each shift ends and who takes over, the incidents still open on the team's services with their notes and log entries, the Datadog monitors currently muted or in alert, and the Jira issues opened during the shift and not yet closed. It also reads the change events PagerDuty recorded, so a deploy that landed mid-shift is not forgotten.

Before the shift boundary it drafts the note: what is open, what was silenced and until when, what was promised, and what to watch. The outgoing engineer edits and approves it. Only then is it posted to the team's channel and attached as a note on each open incident. Nothing is written until they say so.

This is a reference listing. It documents what Fibric would read from On-call Handoff and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Schedule membership and the current and next on-call through GET /oncalls and GET /schedules/{id}/users in PagerDuty
  • Open incidents on the team's services with their notes and log entries, and change events on those services
  • Monitors in Datadog that are muted, in alert, or reporting no data, with the mute expiry where one is set
  • Datadog incidents with their todos and responders
  • Jira issues created or transitioned during the shift, through a JQL search bounded by the shift times
  • Messages in the team's channel during the shift, for decisions that were made in chat and not written down

Proposed actions

  • Target capability: propose the handoff note as a draft for the outgoing engineer, structured by open incident, silenced monitor, open ticket, and watch item
  • Target capability: propose posting the approved note to the team's Slack channel or Zoom Team Chat channel
  • Target capability: propose a note on each open PagerDuty incident with the handoff summary for that incident
  • Target capability: propose a Jira issue for each follow-up the outgoing engineer names that has no ticket yet
  • Target capability: propose a schedule override in PagerDuty when the outgoing engineer records that someone else is covering

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Hand over three open incidents cleanly

    At the shift boundary the draft lists each open incident with its latest note, the muted monitors and their expiry, and the tickets raised. The engineer trims it and approves; it posts to Slack and onto each incident.

    With PagerDuty, Datadog, Slack

  • Turn promises into tickets

    The engineer wrote in chat that the disk alert needs a threshold change. The draft shows it under follow-ups and proposes a Jira issue so it survives the handoff.

    With Slack, Jira

  • Record who really took the pager

    The next on-call is out sick and a colleague agreed to cover. The engineer notes it in the draft; the operator proposes a PagerDuty override for the shift and posts the note to Zoom Team Chat.

    With PagerDuty, Zoom Team Chat

Requirements

  • A PagerDuty REST token that can read schedules, oncalls, incidents, notes, and change events for the team's services
  • A Datadog API key and application key scoped to read monitors and incidents
  • A Jira project and a JQL filter that names the team's work
  • A channel in Slack or Zoom Team Chat where the note is posted, and the shift boundaries as PagerDuty defines them
Authentication
On-call Handoff authenticates through nothing but the connectors: PagerDuty and Datadog for reads, Jira for tickets, and Slack or Zoom Team Chat for the posted note, each with its own token.

Limits

  • It drafts only from what the systems hold. Work done elsewhere enters the note only when the engineer adds it.
  • A schedule override is proposed only when the engineer states who is covering; the operator never chooses a substitute.
  • Muted monitors without an expiry are listed as muted indefinitely; the operator does not unmute them.
  • The note is posted only after the outgoing engineer approves the draft. A shift with no approval produces no post.

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request On-call Handoff ↗

Questions and answers

What does the outgoing engineer approve?
The note itself, as a draft they can edit line by line, plus any follow-up tickets and a schedule override if they named a cover. Approval posts the note and applies those items. Anything they delete from the draft is not posted.
What is kept afterwards?
The approved note, the draft it came from, the incidents and monitors it referenced by ID, the tickets it created, and the channel post ID. Successive notes form the shift log for the service.
Does it act during the shift?
No. It reads continuously so the draft is ready, but it writes only at the boundary and only what the engineer approved. It never acknowledges, resolves, or reassigns an incident.
Ask about On-call Handoff

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy