The Problem: The Disconnected Incident Room
When production breaks at 3 AM, PagerDuty pages the on-call engineer. Responders assemble, diagnose the issue, mitigate the failure, and acknowledge or resolve the incident.
Thousands of critical context bits are generated in that frantic window:
- Which service degraded first?
- Who was the incident commander?
- What was the urgency level?
- What raw alerts fired from monitoring systems?
Yet once resolved, this rich operational history disappears into closed ticket archives. When your team asks an AI agent "What triggered our last payment gateway degradation?" or "Who usually leads recovery on our Kafka clusters?", the agent is clueless because that operational context was never connected to its memory graph.
In this post, we explain how we built a production-grade PagerDuty data-source connector for Cognee to bridge this gap.
What is Cognee?
Cognee transforms raw unstructured text into structured, searchable Knowledge Graphs and vector embeddings for AI agents. Rather than running blind RAG over uncurated chunks, Cognee builds an explicit entity-relationship memory graph so agents can query complex operational dependencies.
Connector Architecture & Design
Connecting PagerDuty to Cognee required solving several real-world requirements:
1. Document-First Synthesis
Cognee extracts entities from natural prose. Instead of dumping arbitrary JSON schemas, our connector synthesizes PagerDuty incident payloads into structured Markdown:
- Incident title & unique ID
- Status (Triggered, Acknowledged, Resolved)
- Urgency level (High, Low)
- Impacted service attribution
- Incident commander and on-call responders
- Associated alert events and monitoring triggers
2. Offset-Based Pagination
PagerDuty v2 REST API exposes /incidents paginated with limit (max 100) and offset. The connector iterates until more=false or no records remain, ensuring complete historical coverage without skipping records.
3. Rate Limiting with Exponential Backoff
PagerDuty APIs enforce rate limits. Our HTTP client automatically catches HTTP 429 and 5xx errors, extracts the Retry-After header when available, and falls back to an exponential backoff strategy (2^attempt seconds) up to 5 retries.
4. Forget-on-Delete Lifecycle
Using write_disposition="replace", Cognee maintains a fresh snapshot of all active and resolved incidents. If false-alarm incidents are deleted or retracted upstream, Cognee's orphan_cleanup purges their entities automatically.
Quick Demo: Ingesting PagerDuty with Cognee
`python
import asyncio
import os
import cognee
from cognee_community_connector_pagerduty import pagerduty_source
async def main():
# Configure connector with high-urgency filter
source = pagerduty_source(
api_token=os.environ["PAGERDUTY_API_TOKEN"],
urgencies=["high"]
)
# Ingest and construct Knowledge Graph
await cognee.add(source)
await cognee.cognify()
# Query operational memory
answer = await cognee.search("Who resolved the last payment outage and what service was affected?")
print(answer)
if name == "main":
asyncio.run(main())
`
Quality & Testing
We wrote a suite of 27 offline unit tests using standard library mocks covering:
- Markdown rendering across all status and urgency permutations
- Robust fallback when responders or services are unspecified
- Client URL building and query-parameter serialization
- Rate-limit backoff header handling
- End-to-end dlt pipeline row generation
Get Involved
- GitHub PR: #485 on topoteretes/cognee-community
- GitHub Issue: #6288 on topoteretes/cognee
- Cognee Core: topoteretes/cognee
If your team uses PagerDuty, try ingesting your operational history into Cognee and let us know what you think!
Top comments (0)