A tired decision record is a short, dated note that captures what you changed, why you changed it, and what you would need to see before reversing it. It sits next to incident timelines, runbooks, and backup drill logs in the operational memory of a small technical team. For a group of two to fifteen engineers running cloud-native services without dedicated SRE coverage, this kind of record matters because the person who made the call at 02:14 is often the same person who has to defend it three months later during an audit, a promotion review, or a post-incident discussion.

Adjacent concepts include decision logs, architecture decision records, runbook annotations, and post-incident review notes. The common thread is that the record must be useful to someone who was not in the room and not in your head. This article describes a repeatable format, shows where it fits in a lean team’s existing workflow, and explains how to write a record that survives contact with daylight.

Why Tired Decisions Need a Different Kind of Record

Most decision documentation assumes a calm room, a clear head, and time to weigh options. That assumption fails for the decisions that actually shape infrastructure: the 02:00 database failover, the emergency firewall rule added during a DDoS attempt, the quick IAM policy change that got a deployment unstuck. These decisions are made under time pressure, with incomplete information, and often by the least-senior person on call.

A tired decision record does not try to make the decision look more rational than it was. It captures the actual reasoning, including the parts that were guesses. That honesty is what makes the record useful later. If the guess was wrong, the record tells you which assumption to check first. If the guess was right, the record tells you which pattern to reuse.

For lean teams, the cost of not writing these records shows up in three places:

• Repeat incidents: The same failure happens again because nobody wrote down why the first fix was chosen.
• Slow onboarding: New engineers cannot tell the difference between a deliberate design choice and an accident of history.
• Audit friction: Compliance reviews ask for evidence of change control, and an empty decision log is a finding.

What a Tired Decision Record Contains

The format should be short enough to complete in under five minutes. If it takes longer, it will not get written at 02:30. A workable structure has five fields:

1. Context and trigger

One or two sentences about what was happening. Name the service, the alert, the error rate, the latency spike, or the failed deployment. For example: “API gateway returning 502s for 40% of requests after the 23:40 deploy of v2.4.1.” This anchors the decision to a specific event, not a general feeling.

2. Decision and action taken

State exactly what you changed. Include the command, the config diff, the IAM policy name, the database parameter, or the rollback commit hash. Vague language like “adjusted settings” is useless three months later. Write “Set max_connections from 200 to 400 on the primary RDS instance” or “Rolled back to commit a3f9c21.”

3. Reasoning and alternatives considered

This is the core of the record. Write what you believed at the time, even if it was a hunch. Then list the alternatives you rejected and why. For example: “Chose to increase connection limit instead of restarting the app because restart would have dropped in-flight orders. Considered scaling read replicas but that would not help write contention.” This section is where the record earns its keep during a later review.

4. Signals to revisit

Define what would make you change the decision. This can be a metric threshold, a time window, or an event. For example: “Revisit if connection count stays above 350 for three consecutive days” or “Revisit after the next load test.” This turns a one-time call into a testable hypothesis.

5. Fatigue note

One honest line about your state. “Written at 02:14 after being awake for 19 hours.” This is not an excuse; it is a signal to future readers about how much weight to give the reasoning. It also helps the team track whether too many critical decisions are being made by exhausted people, which is itself an operational risk.

Where to Store the Record

The storage location matters more than the format. A decision record that lives in a personal notebook or a chat thread is lost to the team. A record that lives in a wiki nobody reads is only slightly better. For lean teams, the best location is the same place the team already looks during an incident: the runbook repository, the incident channel’s pinned thread, or a decisions/ directory in the infrastructure repo.

If the team uses Git for infrastructure as code, store decision records as Markdown files in the same repo. A file named decisions/2025-03-14-rds-max-connections.md is discoverable, versioned, and reviewable. If the team uses a wiki, create a page per decision with a consistent title pattern. The key is that the record is adjacent to the code or config it changed, not in a separate system that requires a different login.

For teams that already maintain runbooks, a decision record can be a section at the bottom of the relevant runbook page. This works well for decisions that affect a specific procedure, such as a backup restore step or a failover threshold. The internal article Write the Recovery Checklist Before You Need It describes how to structure runbooks so that decision notes have a natural home.

Writing the Record When You Are Still Tired

The hardest part is writing the record at all. The following sequence has worked in practice for small teams:

1. Write the action first. Before you close the terminal, paste the command or config change into the record. This takes thirty seconds and captures the most perishable information.
2. Write the trigger second. One sentence about what you were responding to. Do not edit it; write it as you would tell a colleague on the phone.
3. Write the reasoning third. Use bullet points, not prose. Three bullets maximum. If you cannot think of three, write one.
4. Write the revisit signal fourth. If you cannot think of one, write “Revisit at next business day standup.” That is a valid signal.
5. Write the fatigue note last. One line. Done.

This order works because it front-loads the factual content and defers the reflective content. By the time you reach the reasoning section, the action and trigger are already captured, so the record has value even if you stop halfway.

Reviewing Tired Decisions Later

A tired decision record is not a permanent commitment. It is a snapshot of reasoning at a moment in time. The team should review these records on a regular cadence, ideally as part of an existing incident review or a weekly operations sync. The review asks three questions:

1. Was the decision correct? Check the revisit signal. Did the metric cross the threshold? Did the load test happen? What was the outcome?
2. Is the reasoning still valid? If the decision was correct but the reasoning was wrong, the record is a warning sign. The team got lucky, and the next similar decision may not go the same way.
3. Should the decision become a policy? If the same tired decision has been made three times, it is no longer a one-off. It is a pattern that should be codified into a runbook, an alert threshold, or a default config.

This review loop is what separates a decision log from a diary. A diary records what happened. A decision log feeds back into the team’s operational defaults.

Example Record

Here is a complete example from a fictional e-commerce team running on AWS. The record is written as a Markdown file in the infrastructure repo.

# Decision: Increase RDS max_connections on primary

Date: 2025-03-14 02:14 UTC
Author: J. Chen (on-call)

## Context and trigger
API gateway returning 502s for 40% of requests after the 23:40 deploy of v2.4.1. RDS primary at 200/200 connections. App logs show connection pool exhaustion.

## Decision and action taken
Set max_connections from 200 to 400 on the primary RDS instance (db.t3.large, parameter group app-pg-v3). Applied via AWS CLI, not Terraform, to avoid a full apply cycle.

## Reasoning and alternatives considered
- Believed the deploy increased connection churn due to a new retry loop in the checkout service.
- Considered rolling back the deploy, but that would have taken 10+ minutes and the checkout service was already degraded.
- Considered restarting the app to clear stale connections, but that would have dropped in-flight orders.
- Chose to raise the limit because it was reversible and low-risk.

## Signals to revisit
- Revisit if connection count stays above 350 for three consecutive days.
- Revisit after the checkout service retry loop is fixed in v2.4.2.
- Revisit if the RDS instance shows memory pressure (freeable memory below 500 MB).

## Fatigue note
Written at 02:14 after being awake for 19 hours. Reasoning may be incomplete.

This record is about 200 words. It took less than five minutes to write. It contains enough detail for a colleague to understand the decision, challenge it, or reverse it safely.

Common Failure Modes

Three failure modes show up repeatedly in teams that try to adopt this practice:

1. The record is too long

When a decision record becomes a three-page essay, it stops being written. The five-field format above is a ceiling, not a floor. A one-line record with the action and the trigger is better than no record. The team can add reasoning during the next business day review.

2. The record is stored in the wrong place

A decision record in a personal notebook, a direct message, or a closed ticket is not a team asset. The record must be in a location that the team already uses for operational work. If the team does not have such a location, that is a separate problem to fix first.

3. The record is never reviewed

An unreviewed decision record is a tombstone. It marks where a decision was buried. The review loop is what turns the record into a learning mechanism. Without review, the team will keep making the same tired decisions and never know whether they were right.

How This Fits the Gray Haven Approach

Gray Haven’s editorial position is that operational resilience for lean teams comes from repeatable, boring practices, not from heroic effort or expensive tooling. A tired decision record is a boring practice. It takes five minutes, uses tools the team already has, and pays off in fewer repeat incidents and faster onboarding.

The practice also connects to the other pillars of this site. Decision records feed into recovery checklists by documenting why a particular recovery step exists. They feed into incident learning by providing the raw material for post-incident reviews. They feed into access hygiene by recording who made a change and why, which is useful when an IAM policy or firewall rule needs to be audited.

For teams that want to go deeper, the next step is to define a decision record template in the team wiki and a review cadence in the operations calendar. The template should be short enough to fit on one screen. The cadence should be frequent enough that records do not pile up. A weekly fifteen-minute review of the past week’s tired decisions is a reasonable starting point.

Frequently Asked Questions

What is the difference between a tired decision record and an architecture decision record?

An architecture decision record (ADR) captures a deliberate design choice made with time to weigh options. A tired decision record captures an operational change made under time pressure, often with incomplete information. The tired decision record is shorter, more honest about uncertainty, and includes a fatigue note. Both are useful, but they serve different purposes. A lean team may use ADRs for planned architecture changes and tired decision records for emergency operational changes.

How long should a tired decision record be?

Under 300 words. The five fields—context, action, reasoning, revisit signal, fatigue note—can each be one or two sentences. If the record takes more than five minutes to write, it is too long. The goal is to capture the decision before the details fade, not to produce a polished document.

What if I make a tired decision and later realize it was wrong?

That is a normal outcome. The record’s value is not in being right; it is in making the reasoning visible so the team can learn from the miss. When a tired decision turns out to be wrong, update the record with a short note about what actually happened and what the team would do differently next time. This turns a mistake into a training artifact.

Do tired decision records work for compliance audits?

They can, if the records are stored in a consistent location and include the action taken, the author, and the date. Auditors generally want evidence of change control and a rationale for emergency changes. A tired decision record provides both. The key is consistency: if the team writes records for some changes but not others, the audit value drops sharply.

Next Step for This Site

This article is part of a planned series on operational memory for lean teams. The next article will cover how to run a fifteen-minute weekly review of tired decision records without turning it into a status meeting. If you have a tired decision record format that works for your team, or a story about a decision that looked different in the morning, send it in. The best reader examples will be included in a follow-up post with attribution.