RCA within 5 business days: what your MSA actually obligates

If you sell software to enterprises, your MSA almost certainly commits you to a written root cause analysis within a fixed window after a Sev1. The most common pattern is a preliminary notice inside 24 to 48 hours and a finished RCA within three to five business days, with service credits when it is late. Most engineering teams have never read the clause and are measured against it anyway.

What does the RCA clause in an enterprise MSA usually say?

The language varies by customer, but once you have read a dozen master service agreements from Fortune 500 procurement teams the pattern is unmistakable. Three obligations appear together, tied to the severity definitions in the SLA schedule.

• Preliminary incident notice. Within 24 or 48 hours of a Severity 1 incident, the vendor notifies the customer in writing: what was affected, for how long, current status, and an expected date for the full report.
• Written root cause analysis. Within N business days of resolution, the vendor delivers a document describing the cause, the impact, the timeline, and the corrective actions taken or planned. Five business days is the mode; three is common in financial services and healthcare; some agreements allow seven or ten.
• Remedies. Failure to deliver the RCA on time is treated like any other SLA miss: credits against the next invoice, and repeated failure as a route to material breach. Some contracts also allow the customer to require an executive review meeting.

Two things about this clause matter more than its exact wording. First, it is a hard deadline on a document, not on restoring service. Your uptime can be fine and you can still be in breach. Second, the clock usually starts at resolution, when the engineers who understand what happened are exhausted and being pulled back to their roadmaps.

Why do teams miss the RCA window?

Nobody misses it out of indifference. They miss it because the work of producing the document was never designed; it just accumulated. A typical timeline for a five-day obligation looks like this.

Every step in that table has the same shape: the person with the knowledge is not the person with the obligation. Customer Success owns the promise. Engineering owns the facts. Problem Management, where it exists, owns the process but has no tooling for it. And the document itself is the last thing produced rather than a by-product of the investigation.

There is a quieter cost too. When the RCA is late, the customer’s procurement team files it. At renewal, “late RCAs” is a line item in the vendor-risk review sitting next to your uptime numbers, and it is much harder to argue with.

How should you instrument Time to RCA?

You already measure time to detect and time to restore. Almost nobody measures the metric the contract actually cares about. We call it Time to RCA: the elapsed time from incident resolution to delivery of an accepted written root cause analysis. Instrument it in four steps.

1. Record the obligation per customer. Pull the RCA window and the preliminary-notice window out of every MSA into a single register: customer, severity definition, N business days, credit terms. Most companies find that this register does not exist and that the windows are inconsistent.
2. Start the clock automatically. When an incident is marked resolved in your incident tool, open a linked RCA task with the due date computed from the strictest affected customer’s window. Do not rely on someone remembering.
3. Distinguish delivered from accepted. An RCA the customer sends back with questions has not discharged the obligation. Track acceptance, and track how many rounds it took.
4. Report it monthly next to MTTR. Median and p90 Time to RCA, percentage delivered inside the window, credits paid or waived. The number is usually uncomfortable the first month, which is the point.

Benchmarks by severity and by industry, and a longer treatment of the metric, are on our RCA SLA benchmarks page.

What does a compliant customer-facing RCA contain?

The clause says “root cause analysis” and rarely defines it, so the document that discharges the obligation is the one the customer’s own vendor-risk process will accept. In practice that means it survives two readers: an engineer at the customer who wants to know it will not happen again, and a procurement or risk analyst who wants to know you understand what happened. Content that reliably clears both:

• Incident identity and impact. Reference, severity, services affected, start and end time, duration, and which customer-visible functions were degraded.
• Timeline. Detection, escalation, cause identification, mitigation, resolution, in the customer’s timezone.
• Root cause, stated plainly. The trigger, how it propagated, and the failure. Contributing factors are listed separately so the customer can see you distinguish them.
• What changed. If a deployment, configuration change or provider event was implicated, say so at the level of “a configuration change to the routing layer”, not the file path or the engineer’s name.
• Corrective actions. Each with an owner role (not a person), a target date, and its status.
• Confidence statement. What you are certain of, what you inferred, and what you could not determine. Customers trust a document that admits a gap far more than one that claims certainty everywhere.

Just as important is what is removed: internal hostnames, employee names, raw log lines, and any architectural detail that is not needed to explain the cause. That sanitisation is where late-night drafts go wrong, because it is done by hand at the end rather than generated as a distinct artifact from the same evidence. We show a full example on the customer-facing RCA page, alongside the internal report and the evidence pack that sits behind it.

Who should own the RCA obligation?

The honest answer is that in most companies nobody does, which is why it is late. Where it works, a Problem Management function or a designated incident lead owns the deliverable and the deadline, and engineering owns the facts. That only functions if the investigation itself is fast enough that the document is not the bottleneck: if reconstructing what happened across five tools takes three days, no amount of process ownership gets a five-day RCA out on day three.

That is the gap a managed root-cause service exists to close. The investigation runs inside your own environment on the observability you already have, the internal report and the sanitised customer version are generated from the same evidence, a human signs off, and the whole thing arrives inside a committed window with credits if it does not. The contract you owe your customer gets mirrored by the one your vendor owes you. Read how it works, or take your last ninety days of Sev1 tickets and run the replay to see how many of your recent RCAs would have landed inside the window.