Just saw the announcement in my inbox. PagerDuty's new "AI Copilot" is supposed to analyze past incidents and suggest next steps or runbook actions. The demo shows it auto-generating a summary and pointing to "similar past incidents."
My immediate low-level curiosity kicks in: **What's the actual data source and latency here?** Is it just querying their own incident timeline comments, or could it theoretically hook into external observability data (like, say, a trace or log pattern from our own systems) via an API? The overhead concern is real—if this thing is polling or streaming data during an active P1, the last thing we need is extra network chatter on our side.
Some specific things I'm wondering:
* Is the "similarity" check just based on title/description text, or does it parse alert payloads? If it's the latter, that's a much more interesting (and complex) data pipeline.
* How would this play with custom actions or webhooks we've already set up? Can the AI's suggestions be fed *into* an automated remediation script, or is it just a human-in-the-loop suggestion box?
* The post-incident workflow part is intriguing. If it auto-generates the first draft of a post-mortem from the incident timeline, that could save real time. But I'm skeptical about accuracy.
Anyone poking at the beta yet? I'm particularly interested in the integration mechanics. Is there an API endpoint we'd need to expose for it to fetch relevant system state, or is it all self-contained within PagerDuty's own data?
```json
// Hypothetical - would we configure something like this for richer context?
{
"ai_assist": {
"external_context_endpoints": [
"https://internal-api.monitoring/log_patterns",
"https://prometheus.example.com/api/v1/query"
],
"allowed_actions": ["suggest_runbook", "draft_summary"]
}
}
```
Or is it much simpler and just a fancy text parser on the existing incident data? The devil's always in the implementation details.
System calls per second matter.
Great questions. The data source question is huge - I'd bet they're using the existing incident timeline data (title, description, comments) as the initial vector source because it's already structured in their system. Tapping into external observability data in real-time during a P1 seems like a massive reliability risk for them, unless it's a pre-configured, passive hook.
That similarity check is the key. If it's just title/description text, it's basically a fancy search. If it's parsing alert payloads and log snippets attached to incidents, then the embeddings could actually find non-obvious patterns. But that means they built a pipeline to chunk and index all that semi-structured data.
> How would this play with custom actions or webhooks we've already set up?
This is my biggest unknown. If the AI suggestion is just a text blob in the UI, it's kind of weak. If they expose it as a structured event that can trigger an existing webhook - maybe with a confidence score - then we could automate the decision to execute a runbook. That'd be a game changer, but also a scary new failure mode.
Let us know if you find any API docs on it. The devils in the details with these features.