Your on-call engineer just got paged. Here's what happens to the postmortem.

Giga Kovaliovi — Fri, 10 Apr 2026 11:11:53 +0000

The problem nobody wants to admit

It's 3:47am. The alert fires. You and two engineers spend 90 minutes triaging a database connection pool exhaustion. The service recovers at 5:11am.

By 9am, your Slack has three messages: "Can someone write up the postmortem?" Nobody does. By Friday it's a ticket in the backlog. By next week, it's gone.

This isn't a discipline problem. It's a friction problem. Postmortems are painful to write — especially after a night incident where you're running on adrenaline and three cups of coffee.

What Opsrift actually does

Opsrift connects to your monitoring and alerting stack — PagerDuty, OpsGenie, Datadog, or Grafana — pulls the incident data, and generates a complete structured postmortem in under 60 seconds. Not a blank template — a filled document with:

Incident timeline (auto-built from your alert source events)
Root cause section (framed as "AI hypothesis — verify before publishing")
Impact summary with MTTA/MTTR calculated automatically
Action items pushed to Jira in one click
Confluence publish in ADF format — one click
Slack notification on publish

Six tools total: Postmortem Generator, Shift Handover Generator, Runbook Generator, Incident Assistant, Status Page Generator, and Incident Forecast. All pull from the same 9 integrations.

Incident Assistant — the tool we actually use most

During a live incident, paste your alert or import it from PagerDuty/OpsGenie/Datadog. You get:

Plain-English summary of what the alert means
3–5 likely causes ranked by probability
Specific investigation steps with commands
Relevant Confluence runbooks if connected
Escalation guidance

Not replacing your judgment. Saving you 15 minutes of tab-switching at the worst possible moment.

Incident Forecast — the tool that's easy to miss

After enough incidents accumulate, patterns emerge. Which services fire most often? Which time windows are highest risk? Which action items never get closed?

Incident Forecast surfaces these signals proactively — so your team can prioritize reliability work before the next P1 fires, not after.

Who it's built for

SRE and DevOps teams running PagerDuty, OpsGenie, Datadog, or Grafana in a 24/7 environment
NOC teams who need shift handovers that contain the right context
iGaming and FinTech ops where documentation speed directly affects SLA compliance

Try it free

7-day free trial — all 6 tools, all 9 integrations, no commitment. Start with the Incident Assistant if you're mid-incident.

→ opsrift.com

I built an AI tool for incident investigation (looking for honest feedback)

Giga Kovaliovi — Fri, 27 Mar 2026 12:42:45 +0000

Hey everyone 👋

Over the past couple of weeks, I’ve been building a side project called Opsrift.

It started from a pretty simple frustration:postmortems, handovers, and incident documentation take way too much time — and most of it is repetitive.

But while building it, I realized something more interesting:

The real problem isn’t writing postmortems.It’s understanding what actually happened during an incident.

So I ended up going a bit further than just a generator.

What Opsrift does right now

The platform is focused on incident workflows — mostly for people working in SRE, support, or operations.

Right now it includes:

Postmortem generator

Takes incident data and generates structured postmortems in seconds.

Handover generator

Useful for shift-based teams — turns messy updates into clean handovers.

Runbook generator

Creates structured runbooks based on incident patterns or inputs.

Incident Investigator (main focus)

This is the part I’m most interested in:

Pulls data from tools like Jira, PagerDuty, and Opsgenie

Correlates it with deployments from GitHub

Tries to reconstruct what actually happened (timeline, possible causes, etc.)

The goal is to reduce the time spent jumping between tools during investigations.

Status page

Basic external communication for incidents.

Integrations

Current integrations:

Jira

PagerDuty

Opsgenie

GitHub

Slack

Confluence

Still early — some of these are rough.

What it’s NOT (yet)

I want to be upfront:

It’s not a replacement for your incident management tools

It’s not perfect at root cause analysis

It’s not “production-grade” in every edge case

Right now it’s closer to:

an AI layer on top of your existing tools to speed up investigation and documentation

Known issues

To save you time:

GitHub login ❌ (bugged right now)

Slack login ❌ (also bugged)

👉 You can still use:

Google login

Email/password signup

Fixing these next.

What I’m trying to figure out

This is where I’d really appreciate help.

I’m trying to validate a few things:

Does the Incident Investigator actually help or is it just “nice to have”?

Are the outputs accurate enough to be trusted?

Would you use something like this in real workflows?

What’s missing for it to be genuinely useful?

Where I want to take this

Longer term, I’m thinking about moving beyond just generating outputs and more into:

detecting patterns across incidents

identifying unstable services

highlighting teams with high escalation rates

correlating deployments with incidents automatically

Basically:

turning incident data into something you can actually act on

If you want to try it

👉 https://opsrift.com

No pressure — even quick feedback is super helpful.

Final note

I’ve worked in NOC/SOC and incident-heavy environments, so this is very much a “scratch your own itch” project.

That said, I’m aware tools like this can easily become:

too generic

inaccurate

or just another dashboard nobody uses

So I’d rather get honest feedback early.

Even if it’s:

“this doesn’t solve anything for me”

That’s useful.

Thanks in advance 🙌

DEV Community: Giga Kovaliovi