An On-Call Journal for the Pages You'll Forget

2026-09-24 · Yesterself

At 3:40 in the morning the graph goes flat and the page clears. Right then, you know more about that system than anyone will know for the next six weeks. You know which dashboard lied. You know which command actually did something and which one you ran out of habit. You know that you skipped step four of the runbook because step four has never once been the problem.

By nine you will be in a standup saying "the queue thing again, it cleared on its own." Six weeks later, in the planning meeting where you ask for time to fix it, you will have that sentence and nothing else.

An on-call journal is the ninety seconds that closes that gap.

Ninety seconds, not a postmortem

This is not incident documentation. The incident channel, the ticket, the timeline — those capture the incident. They record what happened to the system.

The journal records what happened to the operator. What confused you. What you guessed at. What you were afraid to touch because you weren't sure it was safe to restart. None of that belongs in the formal record, and all of it is the raw material for making next quarter quieter.

So the constraint is hard: write it before you go back to sleep, and keep it under two minutes. If it takes longer, you will stop doing it by Wednesday.

The five lines

Write these in whatever order they come out. Half sentences are fine.

1. What woke me. Two things, not one: the alert as it was worded, and the condition as it actually was. The alert said p99 checkout latency above 800ms. The condition was one node had a full disk and was failing slowly instead of loudly. The distance between those two sentences is the single most useful thing you will write all week, and it is the thing you will forget first.

2. What I looked at first, and whether it helped. If you opened three dashboards before the fourth one told you anything, write down the order. Dashboard order is a map of where your team's instincts have drifted away from where the truth lives.

3. What I did. The commands, in sequence, including the ones that did nothing. Especially those. A step that had no effect at 3 a.m. is a step someone else will also try at 3 a.m. unless it's written down as a dead end.

4. What the runbook was missing. More on this below. It is the load-bearing line.

5. What would have to change for this page to stop existing. One sentence, even a lazy one. "Alert on disk before it alerts on latency." "Give the on-call read access to the billing console." "This should retry itself twice before it wakes anyone."

Do it from your phone, in one plain note or a voice memo you transcribe later. Do not reopen the laptop. The point is to catch what you know before sleep takes it, not to start a second shift.

A note, since on-call and sleep are inseparable: disrupted sleep on rotation is real and it accumulates. Writing things down is a memory practice, not a treatment. If the schedule is affecting your health, that is a conversation for a doctor and for your manager, not something a notebook resolves.

The runbook line is the one that converts

Every other line is context. Line four is the one that turns into work, because it names a specific defect in a specific document that a specific person can fix this week.

What you'll find, over a rotation, sorts into four kinds:

• A step that no longer matches reality. The dashboard was renamed, the service moved, the flag is gone.
• A step that assumes access you don't have at 3 a.m. You had to wake someone up to click one button.
• A decision the runbook refuses to make for you. "Escalate if the impact is significant" is not a threshold, and at 3 a.m. you are not the right person to invent one.
• A whole branch that isn't written down at all, because exactly one person knows it and they were asleep.

If you can edit the runbook the same week, do it while the memory is warm — a five-line correction is worth more than a rewrite you never schedule. If you can't, the journal line becomes the ticket description, already written.

From a rotation to a case

At the end of a rotation, read your entries in one sitting and write three sentences at the bottom. That's the whole ritual.

What changes is the quality of what you can say afterward. "The queue alerts are bad" is an opinion, and opinions lose to roadmaps. But if your notes say you were paged nine times about one queue, that seven of those cleared with no action from you, and that the two that mattered both showed a disk symptom the alert never mentioned — that is a countable, checkable argument, assembled from things you observed rather than things you estimated.

That's the honest version of "make the case." You are not producing a study. You are producing a record specific enough that nobody has to take your word for it.

Keep it about the system. If a handoff went badly or someone escalated something that wasn't urgent, that belongs in a direct conversation, not in a file you'll quote from six months later.

Alert fatigue and system rot are not the same complaint

They feel identical at 3 a.m., they need opposite fixes, and a journal is the cheapest instrument for telling them apart.

Alert fatigue is when the alert fires and nothing needed to happen. The signal is wrong. The fix lives at the alert: a threshold, a duration, a dependency, a deletion. Every page where your honest line four was "nothing I did mattered" is a candidate.

System rot is when the alert fires, something genuinely needed to happen, and it's the same something every time. The signal is right. A human being is manually holding a system together, on a schedule, at night. The fix lives in the system, and it is usually larger and more expensive than a threshold change — which is exactly why it needs evidence behind it.

The sorting question is one line: did a human action change the outcome, and was it the same action as last time?

There is a third bucket worth naming, because it disappears if you only look for problems: the page that was correct, needed a person, and was genuinely new. Those are rare, and they're the ones worth waking up for. Noticing how few of them there are is often the argument by itself.

The entry your successor should read

On the last day of a rotation, write one longer note for whoever is next. Three things: what is fragile right now, what you did that hasn't been cleaned up yet, and what you would have paged them about if it had gotten one degree worse.

This is the most immediately useful thing an on-call journal produces, and it takes five minutes.

Six months later

The pages you forget outnumber the ones you remember, and the forgotten ones are where the pattern lives. You reread a February entry and find that you already wrote the fix for the thing that woke you last night, in your own words, and then it went quiet for a while and you let it go.

That rereading is what Yesterself is built around: each morning it brings back one letter from your own past writing — yesterday's note, an on-this-day entry, or a line you postmarked forward to a date you chose. Postmarking a capsule to the week before your next rotation is a natural fit for this. It is a personal journal, not an incident system of record, and it is end-to-end encrypted with no account and no email, so nothing you write about a bad night is sitting in a work tool. Export is free, forever, in open formats, so the archive stays yours.

Tonight, though, it's five lines on a phone. Start with what woke you.

Common questions

What should I write right after a page clears?

Five short lines, in any order. What woke you, what you looked at first, what you actually did, what the runbook was missing, and what would have to change for the page to stop existing.

Isn't this what the incident tool is for?

The incident record captures the incident. The journal captures the operator. Your confusion, your guesses, and the step you skipped are the parts that never make it into the ticket, and they are the parts that fix the runbook.

How do I tell alert fatigue from a real problem?

Ask whether a human action changed the outcome. If nothing you did mattered, the alert is miscalibrated. If the same action mattered every single time, the system is rotting and a person is holding it together by hand.

What if I miss a night?

Nothing breaks. A journal kept for two thirds of a rotation is still enough to count pages and quote yourself in a review. The goal is evidence, not an unbroken chain.

Should I name colleagues in these entries?

Write about the system, not about people. If someone escalated badly, that is a conversation to have directly rather than a line to file away.