A postmortem for an outage that only affected me

I think personal projects deserve small postmortems.

A 14-section document would be too much for a failed blog deploy. I mean a short note.

What broke? Why did I waste time? What should I do next time? That usually covers enough.

When only I am affected, I am very good at saying “it’s fine” and moving on. Then a month later the same thing happens and I have no memory of the first lesson.

a tiny incident#

Say my site deploy fails because one Markdown post has a bad frontmatter date:

published: "some night idk"

Astro rejects it. Vercel rejects the new version too. Visitors still see the old site.

But the new post stays unpublished, and I spend 20 minutes checking the wrong files because I assume the problem is a package issue.

This is small, and still annoying.

timeline#

The timeline is the part I care about most:

01:12 wrote 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 useful line is the embarrassing one.

01:21 assumed package issue for no good reason

That is the lesson. I guessed before reading the error properly.

impact#

For a personal project, impact can be simple:

New post was delayed by 16 minutes.
Existing site stayed live.
No data was lost.
I lost around 15 minutes because I debugged in the wrong order.

The last line matters. Time and attention are the real costs here.

There is no team for my blog. I have some time after work, maybe not enough sleep, and the usual overconfidence that “this will take 2 minutes”.

It never takes 2 minutes.

cause#

Technical cause:

The frontmatter date did not match the schema.

Human cause:

I did not run the build locally.

Process cause:

I did not have a small content checklist.

I like separating these because “be more careful” fixes nothing. It only makes you feel guilty for 30 seconds and then nothing changes.

what I would change#

For this size of problem, the fix should also be small.

Before pushing a post:

pnpm build:astro

Maybe keep a tiny checklist:

date is valid
draft/hidden are intentional
tags are lowercase
description exists

For this kind of issue, that is enough.

A full platform would be silly because I wrote a bad date at 1 AM.

why write it down?#

Memory edits the details over time.

A week later, I will remember “some Astro thing broke”. A month later, I will remember “deploy was flaky”. Six months later, I will probably blame Vercel because that is convenient.

The postmortem says the boring truth: I wrote a bad date and checked logs too late.

Rude, but useful enough for a tiny template:

what broke
who was affected
timeline
cause
what I will change

No ceremony, just enough truth for future me.