The short version
- Any competent platform team can build this. The first eighty per cent is a webhook, a queue and some API calls — genuinely a few weeks.
- The cost is not building it. It is the connectors. Vendors change payload shapes without telling you, and each one is a silent failure discovered during an incident.
- Three cases where building is right: an unusual estate, an existing platform team with spare capacity and a mandate, or a data-residency constraint no vendor satisfies.
- The question to settle first is not build or buy. It is whether anyone will own it in year two, because that is when the internal version quietly stops being maintained.
A senior engineer looking at this product will think, correctly, that they could build it. A webhook endpoint, a table of runbooks, a worker that runs steps, an LLM call, a UI. Three or four weeks for something demonstrable. They are right, and that is the honest starting point for this conversation.
What the first version costs
Roughly what they think. A small team gets to something genuinely useful quickly, and it will be better fitted to their estate than anything bought, because it only has to handle their alerts.
| Piece | Effort | Honest assessment |
|---|---|---|
| Webhook ingest, one source | Days | Genuinely easy. It is an HTTP handler. |
| Runbooks in a table, a step runner | 1–2 weeks | Easy and satisfying to build. |
| An LLM call to classify | Days | Easy to get working, hard to get trustworthy. See below. |
| A basic UI | 1–2 weeks | Or skip it and read the database. Many teams do, for a while. |
| A demo your VP likes | ~4 weeks | Entirely achievable. |
If that is where it ended, nobody should buy anything. It does not end there, and the remainder is unevenly distributed.
Where the cost actually accumulates
a payload shape"] C --> D["Month 6: resolve events
stop matching"] D --> E["Month 8: an engineer catches
a fabricated confidence"] E --> F["Month 9: nobody reads
the output any more"] F --> G["Month 14: the author
changes team"] G --> H(["Month 18: it still runs,
nobody maintains it,
everyone works around it"]) style C fill:#fff4e2,stroke:#f4a03a style E fill:#fde8e8,stroke:#e57373 style H fill:#fde8e8,stroke:#e57373,stroke-width:2px
Two of those deserve detail, because they are the ones teams do not price in.
Connector maintenance is permanent and invisible. Twelve sources, each a vendor that changes payloads on their schedule. The failure is never an exception — it is a field that is now absent, so the service comes out null, so the match rule stops matching, so the runbook silently does not run. You discover it during the incident it should have handled. We found exactly this class of bug in all five of the newest connectors: every vendor sends a thinner payload to close an alert than to open it, so a fingerprint built from labels does not match and the close is dropped. Incidents stay open for ever. Nothing errors.
Trustworthy reasoning is much harder than working reasoning. Getting a model to classify an incident is an afternoon. Getting it to report a confidence that means something — to separate an established claim from an assumed one, to cap itself when the link is only temporal, to state what would settle it — is the difference between output engineers read and output they learn to ignore. And you only find out which you built after your team has stopped trusting it, at which point you cannot get that back.
Three cases where building is right
We would rather name these than pretend the answer is always buy.
- Your estate is genuinely unusual. Bespoke monitoring, an in-house scheduler, a domain where the alerts are not the standard shapes. The connector maintenance argument inverts — you would be maintaining custom connectors either way, and a product's twelve would sit unused.
- You have a platform team with capacity and a mandate. Not "we could find time" — an owner, a roadmap slot, and a named person in year two. If that is real, building gives you exactly what you want and nothing you do not.
- A constraint no vendor satisfies. An air-gapped environment, a residency rule, a model that must be one you host. Worth checking before assuming — InsightResolve is self-hosted and runs with no model at all — but if the constraint is real, it is decisive.
And one case where buying is clearly right
If the motivation is "the on-call rota is unsustainable and we need relief this quarter", building is the wrong instrument. You will have a demo in four weeks and relief in nine months, and the rota does not survive the gap.
The question that actually decides it
Not cost, and not capability. Who owns it in year two?
Internal tools of this kind have a characteristic failure. The author builds it, it works, they move to another team. It keeps running, because it is not broken. A connector breaks silently and nobody notices for a month. Someone adds an alert source by copying the nearest handler. The runbook UI never gets built because reading the database is fine for the three people who know the schema. Two years later it is load-bearing, undocumented, and owned by nobody — which is precisely the key-person problem the tool was supposed to solve, recreated one layer down.
The test to apply
Name the person who will own this in eighteen months. Not the team — the person. If you cannot, that is not an argument against your engineers; it is a statement about how internal tooling is resourced, and it will be just as true after you build it.
A middle path worth considering
Run the demo stack for a month against a copy of your real alerts. It is one compose file and costs an afternoon. Then you are deciding with your own data rather than on principle:
- How many of your alerts do the seeded runbooks already shape-match?
- How often does the agent reach the conclusion your on-call reached?
- On the ones it got wrong, did its confidence reflect that?
- How much of what you would need is connectors you would have to write anyway?
That last question is usually the one that settles it, and it settles it in both directions — we have seen the honest answer be "most of what we need is bespoke" as often as the reverse.
Next in this series
From first runbook to autonomous in ninety days — a sequence that earns trust before it asks for it.