I should write tiny postmortems for tiny outages

Personal projects deserve postmortems too, although mine do not need fourteen sections, a severity matrix, or a meeting where I explain the outage to myself. A small note is enough. I want to know what broke, why I spent time checking the wrong thing, and what tired future me should try first when it happens again.

I am very good at saying “eh, it is fine” when I am the only person affected. The old site stays live, nobody complains, and I close the terminal feeling as if the problem has left with it. A month later the same failure returns and all I can remember is that something about it annoyed me. Apparently annoyance is a poor storage format for operational knowledge.

A deploy small enough to dismiss#

Imagine a site deploy failing because one Markdown post contains this date:

published: "some night idk"

Astro rejects the content and Vercel keeps serving the previous build. Visitors are fine, but the new post remains unpublished while I spend twenty minutes checking packages because I decided, without evidence, that dependencies looked suspicious. The impact is tiny. It still ate part of my evening, and that is enough reason to leave a note.

The timeline is the part I care about most because it records the order in which I became wrong:

• 01:12 wrote the new post
• 01:18 pushed changes
• 01:20 deploy failed
• 01:21 assumed package issue for no good reason
• 01:29 checked build logs properly
• 01:31 found invalid frontmatter date
• 01:33 fixed date
• 01:36 deploy passed

The embarrassing line is the useful one:

01:21 assumed package issue for no good reason

I guessed before reading the error properly. A short impact summary can stay just as plain:

• The new post was delayed by 16 minutes.
• The existing site stayed live.
• No data was lost.
• I lost around 15 minutes because I debugged in the wrong order.

That last line is the reason I bother. Time and attention still count on a personal project, especially after work when I am tired and have announced that something will take two minutes. It almost never takes two minutes.

Keep the fix smaller than the incident#

The invalid date caused the build failure. I made the incident longer by skipping the local build and guessing before reading the log. A small content checklist would have caught both habits. “Be more careful” sounds responsible for roughly thirty seconds and then changes absolutely nothing, so I prefer a command I can actually run:

pnpm build:astro

A short check before pushing content would help too:

• Date parses.
• Draft and hidden states are intentional.
• Tags are lowercase.
• Description exists.

A small checklist is enough for this problem. It should stop me publishing sleepy YAML and remind me to read the first useful error before inventing a more exciting one.

A week later I will remember that “some Astro thing” broke. A month later the deploy itself will seem flaky. Give me six months and I will probably blame Vercel because that is convenient and unfair. The note keeps a less dramatic version of events around: I wrote a bad date and checked the logs too late. That sentence is rude to past me and useful to future me, which feels like a fair trade. My whole template can stay small:

• What broke?
• Who was affected?
• Timeline
• Cause
• What I will change

For a sixteen-minute blog outage, this much truth is enough for future me, who is sadly the same person and will absolutely make the same mistake again if I leave him no evidence.