Reference · built on requestOperator by FibricCustomer support

Outage Notice

Links monitoring incidents to the tickets they generate. Proposes a status macro and a proactive notice to affected customers.

Request accessPricing ↗

About

When a service goes down, the paging tool knows first, the status page knows second, and the help desk finds out from customers. Outage Notice closes that gap in both directions. It reads the incident from PagerDuty or Datadog, the components marked affected on Statuspage, and the tickets arriving in the same window whose subject or tags match. It groups those tickets under one problem ticket so they are answered once.

It then drafts the macro agents apply to incident tickets, the next status page update, and a notice to the customers on the affected components. The incident owner approves each piece separately. The notice goes out once, to the list shown, and the problem ticket's closing comment reaches every linked ticket when the incident resolves.

This is a reference listing. It documents what Fibric would read from Outage Notice 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

  • Incidents in PagerDuty with status Triggered, Acknowledged, or Resolved, their urgency, and the service they fired on
  • Incidents in Datadog through GET /api/v2/incidents and /api/v2/incidents/{incident_id}
  • Statuspage incidents in Investigating, Identified, Monitoring, or Resolved, with the components marked affected
  • Tickets in Zendesk and conversations in Kustomer arriving during the incident window, by subject, tag, and channel
  • Zendesk tickets already typed Incident and linked to a Problem, so a ticket is never counted under two problems
  • Bounce events from Postmark on any notice already sent, so a failed delivery is on the record

Proposed actions

  • Target capability: propose a Zendesk problem ticket for the incident and the link of each matching ticket to it as type Incident
  • Target capability: propose a status macro in Zendesk whose actions set the reply text, tag, and status for tickets tied to the incident
  • Target capability: propose a proactive notice through Postmark or Twilio SendGrid, listing every recipient before anything is sent
  • Target capability: propose the next Statuspage update, its status and text, from what the monitoring tool shows, for the incident owner to post
  • Target capability: propose the closing comment on the problem ticket when the incident resolves, which Zendesk copies to unsolved linked incidents

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

What you can build

  • Link the flood of tickets to one problem

    A PagerDuty incident triggers on the checkout service. Within the window, tickets mentioning checkout arrive in Zendesk. The operator proposes one problem ticket and the incident links; an agent approves and answers once.

    With PagerDuty, Zendesk

  • Tell customers before they ask

    A Datadog incident names the region affected. The operator drafts a notice and lists the customers on that region from your rule; the owner trims the list, approves, and Postmark sends it once.

    With Datadog, Postmark

  • Keep the status page and the help desk in step

    Statuspage moves to Monitoring. The operator proposes the matching Kustomer holding reply and, when the incident resolves, the closing note for every conversation it tagged.

    With Statuspage, Kustomer

Requirements

  • A paging or monitoring connector: PagerDuty or Datadog
  • A support connector: Zendesk with problem and incident ticket types, or Kustomer
  • A delivery connector for notices: Postmark, Twilio SendGrid, or Twilio for SMS
  • A rule from you for who counts as affected: components, plans, or regions
Authentication
Uses the credentials of the paging, monitoring, status page, support, and delivery connectors you attach. It holds none of its own and sends no notice unapproved.

Limits

  • Solving a Zendesk problem ticket solves its linked incidents and copies the comment, but customers on messaging channels are not notified by that route
  • Statuspage lets you notify subscribers only when at least one component is marked affected. An update with no component reaches no subscriber
  • Tickets match an incident by time, subject, and tags. An unrelated ticket from the same hour can match, so the list is shown for pruning
  • The notice is never sent by the operator. A person sends it once, to the recipient list the operator showed

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 Outage Notice ↗

Questions and answers

What does the incident owner approve?
Each piece on its own: the problem ticket and its linked list, the macro text, the notice with its full recipient list, and each status page update. The owner can prune the list, rewrite the text, or skip a piece. Nothing is sent or posted before approval.
What record ties the incident to the tickets?
The incident id from the paging tool tied to the problem ticket, the ticket ids linked under it, the macro applied, the notice text with its recipients and delivery events, each status page update, and who approved what and when.
Does it email customers on its own?
No. The notice is drafted with a recipient list and waits for a person. It is sent once. Bounces reported by the delivery tool are attached to the record, and no re-send is proposed without a new approval.
Ask about Outage Notice

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