"We'll just build it ourselves." The honest answer.

Yes, you probably can build the investigation. A good platform team, given a quarter and a clear brief, can produce an agent that queries your observability tools, proposes a cause for a Sev1 and is right often enough to be useful. We are not going to argue otherwise. The honest question is not whether you can build the investigation. It is whether the investigation is the thing you actually need, and what happens to it eighteen months from now.

What can a platform team realistically build in a quarter?

Quite a lot, and it is worth being specific rather than dismissive. Modern models are good at reading logs, metrics and traces, and the tooling to wire them to your observability APIs is mature. In roughly a quarter, a strong team of two or three engineers can ship:

• An agent that, on incident open, pulls the relevant metrics, log excerpts and recent deployments for the affected services.
• A proposed cause posted into the incident channel, with the queries it ran.
• A rough service map derived from your infrastructure-as-code and traces.
• A template that turns the above into a first-draft postmortem.

That is a real capability, and for a cloud-native company on a single observability vendor with no contractual RCA obligation and no regulator, it may be all you need. If that describes you, build it, and this post is not trying to talk you out of it.

What can a platform team not build?

The gap is not in the investigation. It is in everything around the investigation that turns a faster answer into a discharged obligation.

Four of those rows deserve more than a table cell.

The SLA

An internal tool cannot commit to a deadline in any way that means something. If your build produces the RCA in five days one week and twelve days the next, nobody pays a credit and nothing changes except that a Customer Success manager sends an apologetic email. If you owe your enterprise customers a written RCA in a contractual window, and most B2B software companies do, then what you are buying is not an investigation but a guarantee that the document arrives. Guarantees are the thing services sell and tools structurally cannot. Our RCA SLA benchmarks page covers what windows look like in practice.

Accountability at 3am

When the internal agent proposes the wrong cause during a Sev1, or proposes nothing, the person who deals with that is your on-call engineer, who is also the person the tool was supposed to relieve. When a managed service is wrong, someone else’s engineer is paged, someone else’s evidence pack is reviewed, and someone else pays if the SLA is missed. The value is not that the vendor is smarter. It is that the accountability has moved.

Month eighteen

This is the row that decides most build-vs-buy decisions in retrospect and almost none in advance. Observability vendors change their APIs. Your company adopts a second monitoring stack after an acquisition. The engineer who built the agent moves to another team, and then to another company. The prompt library nobody documented starts returning worse answers after a model upgrade. None of this is anyone’s fault; it is just what happens to internal tooling that lives alongside a roadmap. A vendor’s whole business is keeping that plumbing working, and the maintenance is priced into the service rather than borrowed from your platform team’s next quarter.

The artifact suite

An investigation ends when someone knows the cause. An RCA obligation ends when a document is accepted by the person who was owed it. Between those two points sit the internal report with an evidence index, the sanitised customer-facing version with hostnames and names removed, the one-page executive summary, the change attribution record, the problem-record payload for ServiceNow or Jira, and the evidence pack an auditor asks for. Each is small. Together they are most of the work, and building them well is a product in itself rather than a template.

What is the disarming question?

When this objection comes up in a conversation, we ask one question and then stop talking: what happened to the last internal tooling project your platform team took on alongside their roadmap?

Nine times out of ten the answer is a pause, and then a story about something that reached seventy percent, worked well enough that nobody could justify killing it, and never got the last thirty percent because a customer-facing feature was always more urgent. This is not a criticism of platform teams. It is the correct prioritisation. Their roadmap should win. Which is exactly why the thing that has to arrive on a contractual clock, every time, should not be competing with it.

Ask it of yourselves before you ask a vendor. If the honest answer is “our last three internal tools are all in production, maintained, and documented”, you are in a rare organisation and building is a genuinely strong option.

When should you build?

To be fair to the objection, there are cases where building is right, and we would rather say so than win a deal that churns.

• You have no contractual RCA obligation and no regulator, so nobody outside the company is waiting on a document.
• You run on a single observability vendor with a clean, trusted service map, so integration breadth and ownership resolution are solved problems.
• Your Sev1 volume is low enough that the RCA workload is an irritation rather than a headcount line.
• You have a platform team with slack and a track record of finishing internal tools.

If two or more of those are true, build. If none of them are, and particularly if you owe RCAs to customers or examiners on a clock, the thing you need is a service, and no amount of engineering talent turns an internal team into one.

How do you decide honestly?

Do not decide from a demo, and do not decide from this post. Take your last ninety days of Sev1 tickets, the ones your team already investigated and wrote up, and run them through the vendor’s process blind. Score the output against what your engineers actually found: accuracy, time to cause, quality of the evidence index, quality of the customer-facing document, and where the vendor abstained rather than guessed.

Then put the result in front of your platform team and ask a straight question: can you match this in a quarter, and keep matching it? If the answer is yes, you should absolutely build it, and you will have a far better specification for having seen the target. If the answer is no, you have a very well-evidenced business case for buying. Either way, you have made the decision from your own incidents rather than from a sales conversation. Read how the service works, then run the replay and let the output settle it.