Reference · built on requestOperator by FibricReporting & analysis

Root Cause

The timeline behind a flagged incident built from events, deploys, and customer contacts, with a root-cause summary and tasks proposed.

Request accessPricing ↗

About

After an incident, the timeline is reconstructed from memory and four chat threads. This operator reconstructs it from records. It starts from the incident you flag in PagerDuty and reads its log entries: trigger, acknowledge, escalate, annotate, resolve, each with a time and an agent. It reads deployments to the affected repositories from GitHub, with ref, sha, environment, and status. It reads monitor states and events from Datadog in the window. It reads event counts from your streams and the tickets customers opened while it lasted.

It lays these on one timeline, proposes a summary that names the first change before the first symptom, and proposes follow-up tasks in your work tracker.

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

  • Incident log entries from PagerDuty for the flagged incident, by type: trigger, acknowledge, assign, escalate, annotate, resolve
  • Notes on the incident from PagerDuty, as written by responders during the incident
  • Deployments and their statuses from the GitHub Deployments API for named repositories, filtered by environment and time
  • Events and monitor states from Datadog within the incident window, with tags and sources
  • Event counts per topic or bus from Apache Kafka or Amazon EventBridge for the same window
  • Tickets opened in Zendesk during the incident, by created_at and tags, as the customer-facing side of the timeline
  • Existing issues in Jira or Linear that reference the incident id, so tasks are not duplicated

Proposed actions

  • Target capability: propose the assembled timeline as a page in Confluence or a note on the incident in PagerDuty
  • Target capability: propose a root-cause summary naming the earliest recorded change before the first symptom, with the records it rests on
  • Target capability: propose follow-up tasks in Jira or Linear, one per action the summary calls for, each assigned to a named owner
  • Target capability: propose a tag on the customer tickets it linked to the incident, so their replies can reference one cause
  • Target capability: propose a question to responders where the records leave a gap in the timeline

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

What you can build

  • PagerDuty incident with GitHub deploys

    Log entries from the incident are placed beside deployments to the affected repository. A deploy with status success minutes before the trigger is proposed as the leading candidate, with both records linked.

    With PagerDuty, GitHub, Jira

  • Customer contacts on the timeline

    Zendesk tickets created during the window are counted per hour and placed on the timeline. Approving the link proposes one tag on those tickets so replies cite one cause.

    With Zendesk, PagerDuty

  • Datadog monitors and Kafka topics

    Monitor state changes and events from Datadog and message counts from Kafka topics fill the window between the deploy and the first alert.

    With Datadog, Apache Kafka

  • Follow-ups in Linear

    Each action the approved summary calls for becomes a proposed Linear issue with an owner. Existing issues referencing the incident are linked instead of duplicated.

    With Linear, Confluence

Requirements

  • An incident source: PagerDuty, or Datadog monitors where incidents are declared there
  • A deploy record: GitHub Deployments for the repositories that serve the affected system
  • An observability or event source for the window: Datadog, Apache Kafka, or Amazon EventBridge
  • A support connector for customer contacts during the window: Zendesk, Intercom, or Kustomer
  • A work tracker for follow-ups: Jira or Linear, with a project chosen for incident tasks
Authentication
incidents.read on PagerDuty, a GitHub token with deployment read, a Datadog API and application key with event read, ticket read on the help desk, and issue create on the work tracker.

Limits

  • It orders records by their timestamps. Clock differences between systems are shown, not corrected.
  • A deployment appears only if it was recorded through the GitHub Deployments API. Deploys made outside it leave no record here.
  • The summary names the earliest change before the first symptom. Precedence is evidence, and a person judges whether it is the cause.
  • PagerDuty caps notes at 2000 per incident. A timeline note is proposed as one note, or as a page if it is long.

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 Root Cause ↗

Questions and answers

What do I approve, and can I change it?
The timeline, then the summary, then each task and tag. You see every record with its source and time, the proposed cause and the evidence it rests on. You can reorder, remove a record, or change the cause before approving.
What record is left of the timeline?
The timeline as approved with every record id, the summary text and its edits, each task created with its owner, each tag written, and who approved each step. Gaps it could not fill are recorded as gaps.
Does it resolve incidents or roll back deploys?
No. It reads incidents, deploys, events, and tickets. It never resolves or reassigns an incident, creates a deployment or rollback, changes a monitor, or replies to a customer.
Ask about Root Cause

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