Should Have and Could Have in Postmortems

By the end of this lesson, you will be able to...

• Choose should have when a postmortem names a missed expected action.

• Choose could have when a postmortem names a possible alternative path.

• Rewrite a blame-heavy postmortem sentence into a useful learning sentence.

Idea in one sentence: In postmortems, should have points to a missed expectation, while could have points to an available alternative.

Core Insight

A checkout incident happened on Monday.

During the incident, users could not complete payments for 18 minutes. The team found the immediate cause: a deploy changed the payment timeout, and the rollback path was not tested before release.

In the postmortem, someone writes:

We failed because we did not test rollback.

The sentence is understandable. It is also heavy. It sounds like the main job is to blame a person.

A better postmortem sentence is:

We should have tested the rollback path before the deploy.

This sentence still names the missed action. It does not hide the problem. But it frames the problem as a broken expectation: the rollback path was important enough that testing it belonged in the release process.

Now compare a second sentence:

We could have reduced impact by disabling the new payment timeout.

This does a different job. It does not say the team had a firm duty to disable the timeout. It names an alternative that was available, or possibly available, during the incident.

Both patterns look similar:

should have tested
could have reduced

But they guide the postmortem in different directions.

Should have asks: "What expected action was missing?"

Could have asks: "What alternative path was available?"

The Postmortem Pressure

Postmortems need precise language because they sit between two bad extremes.

One extreme is blame:

The release owner should have known this would fail.

This sentence may create defensiveness. It points at a person more than a system.

The other extreme is vagueness:

Things could have been better.

This sentence is too soft. It does not tell the team what to change.

Useful postmortem English needs a middle path:

We should have tested the rollback path before the deploy.
We could have reduced impact by disabling the new payment timeout.

The first sentence names the missing expectation.

The second sentence names an alternative mitigation.

The grammar helps the team separate prevention from response.

Plain to Precise Bridge

Plain meaning:

You are talking about a past incident and comparing what happened with a better path.

In this scenario:

The team deployed a risky payment change. The rollback path was not tested. During the incident, disabling the new timeout may have reduced the impact.

Technical name:

These are perfect modals:

modal + have + past participle

Examples:

should have tested
could have disabled
could have reduced

The word have points back to the past. The modal says what kind of judgment you are making about that past.

Use should have when the sentence is about a missed expectation, standard, duty, or recommended action.

Use could have when the sentence is about an available option, alternative design, or possible mitigation.

A Worked Revision

Start with a raw postmortem note:

The deploy broke checkout. We did not test rollback. We maybe used the wrong timeout.
We should just be more careful next time. We could have done something.

The note has useful information, but the useful pieces are mixed together.

Let's separate them.

Now the postmortem note is more useful:

The timeout change might have contributed to the checkout failures. We should
have tested the rollback path before the deploy. During mitigation, we could
have disabled the new payment timeout while we prepared the rollback. The release
checklist should require rollback-path testing for payment changes.

Notice the sequence:

1. might have contributed keeps the cause cautious.
2. should have tested names the missed expectation.
3. could have disabled names an alternative response.
4. should require turns the lesson into a future process change.

The naive failure is to make every sentence sound like blame:

The team should have known. The reviewer should have caught it. The owner should
have fixed it faster.

Those sentences may be grammatically correct. But they do not show the mechanism that failed. A postmortem is more useful when the sentence points to a test, checklist, signal, runbook, owner handoff, or mitigation path.

So far:

should have + past action -> missed expectation
could have + past action -> available alternative

When Should Have Is Too Sharp

Should have can sound strong.

That is useful when the expectation was real:

We should have tested the rollback path before the deploy.

The sentence says: "This was expected work. We missed it."

But should have can become too personal when the subject is a person:

Ana should have caught the timeout change.

That sentence may be true in a narrow sense, but it often creates the wrong conversation. It makes one person the center of the failure.

A better postmortem version names the process:

The review checklist should have included timeout changes for payment deploys.

Now the sentence still says what was missing. But the missing thing is a system guardrail, not a person.

This is not about hiding responsibility. It is about making the next action visible.

When Could Have Is Too Soft

Could have is useful for alternatives:

We could have disabled the new timeout during mitigation.

This sentence says the option existed, or probably existed. It does not say the option was clearly required.

That is helpful when you are exploring incident response.

But could have can become too soft when the action was actually expected:

We could have tested rollback before the deploy.

This sentence treats rollback testing as only one possible option. If rollback testing was required by policy, could have is too weak.

Use should have instead:

We should have tested rollback before the deploy.

The difference is the standard.

If the team had a known expectation, use should have.

If the team is naming an option that might reduce impact next time, use could have.

Common Confusions

Confusion: Should have always blames someone

Why it is tempting:

Postmortem sentences often use people as subjects:

The reviewer should have found the missing test.

Better model:

Should have names a missed expectation. You can aim that expectation at the process, artifact, or guardrail:

The release checklist should have required rollback-path testing.

That version is still honest, but it is easier to turn into an improvement.

Confusion: Could have means "we should have done it"

Why it is tempting:

In everyday English, people sometimes use could have to express regret:

We could have avoided this.

Better model:

In technical postmortems, could have often names an alternative path. It may be a possible mitigation, not a clear duty:

We could have routed traffic away from the new checkout path.

To decide whether it was a duty, ask: "Was this already required by policy or known good practice?" If yes, should have may be more precise.

Confusion: Should have and must have do the same job

Why it is tempting:

Lesson 018 used must have for strong past inference:

The worker must have retried after the timeout.

Better model:

Must have reports what the evidence strongly suggests happened.

Should have reports what the team believes was expected but did not happen.

Compare:

The worker must have retried after the timeout.
We should have checked the retry logs during mitigation.

The first sentence is evidence. The second sentence is judgment.

Trade-offs and Limits

Should have improves a postmortem when the team needs to name a missed standard.

It gives the sentence weight, which is sometimes exactly what the review needs:

We should have tested the rollback path before the deploy.

That weight is useful. It tells the reader that rollback testing was not just a nice idea. It was part of safe release work.

The trade-off is tone. If every sentence uses should have, the postmortem can start to sound like a list of accusations:

The reviewer should have caught it.
The release owner should have waited.
The on-call engineer should have disabled the flag sooner.

Those sentences may describe real missed actions, but they make the improvement harder to see. The reader has to translate blame into process work.

A stronger postmortem usually moves one level toward the system:

The review checklist should have required rollback evidence.
The release plan should have named the flag-disable step.
The incident runbook should have shown when to disable the new timeout.

Now the missed expectation is still visible, but the repair target is visible too.

Could have has the opposite risk. It is useful because it keeps alternatives open:

We could have disabled the new timeout during mitigation.

The trade-off is softness. If the action was clearly required, could have can make the postmortem too gentle:

We could have followed the rollback checklist.

If the checklist was mandatory, write:

We should have followed the rollback checklist.

This grammar does not solve the whole postmortem. It cannot prove the root cause. It cannot decide policy. It cannot make a team blameless by itself.

It helps with one smaller job: making the sentence show whether you are naming a missed expectation or an available alternative.

You can see the boundary when a teammate asks:

Was that required, or was it just one possible option?

If it was required, prefer should have.

If it was one possible option, prefer could have.

If you are reporting evidence about what probably happened, go back to lesson 018 and use a past inference pattern such as must have or might have.

Check Your Understanding

Check: The release policy says payment changes need rollback-path testing. The team did not test rollback. Which sentence fits best?

A. We could have tested the rollback path before the deploy.
B. We should have tested the rollback path before the deploy.
C. We must have tested the rollback path before the deploy.

Think first, then reveal.

Answer: B is best. The testing was an expected action, so should have tested names the missed expectation. Could have tested is too soft. Must have tested means the evidence strongly suggests the testing happened, which is the opposite of the situation.

Check: During the incident, the new timeout could be turned off with a feature flag, but the runbook did not require that step. Which sentence fits best?

A. We could have disabled the new timeout during mitigation.
B. We should have disabled the new timeout during mitigation.
C. We must have disabled the new timeout during mitigation.

Think first, then reveal.

Answer: A is best if you are naming an available option. If the runbook clearly required the flag step, then should have disabled would become better.

Practice

Rewrite this postmortem paragraph:

The reviewer missed the problem. The team did not test rollback. We maybe could
do something with the timeout. The deploy broke checkout.

Use this evidence:

payment deploy changed the checkout timeout
rollback path was not tested before deploy
feature flag could disable the new timeout
logs show checkout failures in the new path
the review checklist did not mention timeout changes

Model answer:

The timeout change might have contributed to the checkout failures because the
logs show errors in the new path. We should have tested the rollback path before
the deploy. During mitigation, we could have disabled the new timeout with the
feature flag. The review checklist should include timeout changes for payment
deploys.

Why this works:

• might have contributed keeps the cause tied to evidence.
• should have tested names the missed expected action.
• could have disabled names an available mitigation.
• should include turns the learning into a future process change.

Now try one more small revision.

Change this sentence:

Maria should have noticed the missing rollback test.

A more process-focused version is:

The review checklist should have made the missing rollback test visible.

This version does not erase the mistake. It points to the guardrail the team can improve.

Daily Practice Lines

Read these lines once or twice during the day:

We should have tested the rollback path.
We could have disabled the new timeout during mitigation.
The worker must have retried after the timeout.

The first line is the main missed-expectation line for this lesson.

The second line practices available alternatives.

The third line reviews past inference from lesson 018.

Resources

• [ARTICLE] Cambridge Dictionary Grammar: Past modals
  • Link: https://dictionary.cambridge.org/grammar/british-grammar/past-modals
  • Focus: Compare should have, could have, might have, and must have in past situations.
• [REFERENCE] Google Site Reliability Engineering: Postmortem Culture
  • Link: https://sre.google/sre-book/postmortem-culture/
  • Focus: Notice how incident learning improves when postmortems avoid personal blame.
• [REFERENCE] Microsoft Writing Style Guide: Be clear and concise
  • Link: https://learn.microsoft.com/en-us/style-guide/word-choice/use-simple-words-concise-sentences
  • Focus: Keep corrective technical sentences direct and useful.

Key Takeaways

• Use should have for a missed expectation, standard, duty, or recommended action in the past.
• Use could have for an available alternative, design path, or mitigation in the past.
• In postmortems, aim the sentence at the process or guardrail when that makes the next improvement clearer.
• Keep cause, judgment, and future action separate.