A three-line status note says what you know, what you do not know yet, and when you will check next. Posting it in your ticket or channel keeps everyone working from the same facts, stops rumor from filling gaps, and shows that silence means a scheduled check, not neglect.
Why a short note beats a long one
During unfolding news, people want an answer to "are we affected?" Often the true answer is "we are still finding out." Without a note, that gap fills with guesses, side threads and repeated questions.
A fixed three line format works because it is easy to write when you are busy, and easy to read when others are busy. It also forces honesty. The "do not know" line makes you say what is open.
The template
Known: <facts we have confirmed, with source and time>
Unknown: <what we have not yet confirmed>
Next check: <what we will check, who, and by when>
Keep each line to one or two sentences. If a line grows, move detail into the ticket and link it.
Example 1: early in the day
Known: Maintainer post at 09:40 UTC says versions 2.1.4 and 2.1.5 of the package were published without authorization. We use the package in two services.
Unknown: Which version each service resolved. Whether any build ran during the window.
Next check: Platform team reads lockfiles and CI logs by 11:00 UTC. Update here at 11:15.
Example 2: after the check
Known: Both services pin 2.1.3 in the lockfile. CI logs show no fresh install of the package since last week.
Unknown: Whether any developer laptop installed 2.1.4 or 2.1.5.
Next check: Short message to developers asking them to run the version check by end of day. Close the item tomorrow morning if no reports.
Rules that keep the note useful
- Facts need sources. Add a link and a time. "Known" is for things you or a primary source confirmed, not for what you heard.
- Name the unknowns. A blank unknown line usually means someone has not thought hard enough.
- Give a real time for the next check. "Soon" is not a time. Pick a clock time and a time zone.
- Name an owner. One person per check.
- Update on schedule even if nothing changed. "No change since 11:15, next update 13:00" is a valid update and reassures people.
Where to post it
Pin it at the top of the ticket and mirror it in the one channel where people ask. Edit in place, or add a dated line, but keep one current version at the top. If you make the ticket the source of truth, link it instead of copying text into five places.
For anything customer facing, a note like this is internal. Public statements need their own review. See the post on who approves public incident communications.
What the note is not
It is not a postmortem and not a root cause statement. Do not guess at who did it or why. Keep to what is confirmed, what is open and what happens next.
Example 3: a note that should have been written differently
Here is a weak note, and why it fails.
Known: Looks like a big supply chain issue, probably bad.
Unknown: Not sure how bad.
Next check: Will look into it.
The known line holds a feeling, not a fact. The unknown line is vague. The next check has no owner and no time. Nobody reading this can plan around it.
Now the same situation, rewritten.
Known: Registry notice at 08:55 UTC says versions 4.0.3 and 4.0.4 were published without the maintainer's approval. Our payment service lists the package as a direct dependency.
Unknown: Which version the payment service resolved on its last build. Whether any build ran between 08:10 and 08:55 UTC.
Next check: Sam reads the lockfile and the last three build logs by 09:30 UTC. Update here at 09:40.
Every line can be checked, and every line tells the reader what happens next.
A table of common weaknesses
| Weakness | Example | Fix |
|---|---|---|
| Facts without sources | "We heard it is bad" | Add the link and the time you read it |
| Hidden unknowns | Unknown line is empty | Ask what would change your decision |
| No clock | "Update soon" | Pick a clock time and time zone |
| No owner | "We will check" | Name one person |
| Too long | Five paragraphs per line | One or two sentences, details in the ticket |
| Stale | Last update three hours ago | Post a dated no change line |
How the note changes across the life of an item
The note is not written once. It evolves, and each version tells a story.
Early: most of the content is in the unknown line. That is fine and honest.
Middle: known grows as you check. The unknown line shrinks to a few specific questions. The next check becomes narrower.
Late: unknown is nearly empty. The next check becomes a closing step, such as confirming a clean rebuild or archiving evidence.
Closed: the last version says what you concluded, why, and what evidence supports it. That version is the one a reviewer will read months later.
If you keep each earlier version as a dated line below the top, you get a free timeline.
Pairing it with other habits
The note works well alongside two other habits. First, archive the source you cite, so the known line can be checked later. See the post on archiving a write-up. Second, when sources disagree, record both in the known line with their times and note the conflict in unknown. The post on what to do when two sources disagree covers that case.
Who writes it
The person closest to the facts writes it, usually whoever is running the check. A single writer avoids contradictory versions. If you have an incident lead, they own the note and others send them updates. If you do not, agree at the start of the item who holds the pen.
Make sure the note is easy to find. A pinned message in one channel and the top of one ticket is enough. Five copies in five places is how people end up reading an outdated one.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how findings are grouped by package and version, which is the kind of fact that belongs on the known line.
Quick check
Why include an unknown line?
It makes open questions visible, so people stop treating missing information as good news or bad news.
What if nothing has changed at the next check time?
Say so in a short update and set the next time. Silence reads as neglect, a dated no-change note reads as control.
Who should write the note when several people are working on the item?
One person, usually whoever runs the checks or leads the response. Others send them updates so there is a single current version.
Last reviewed: 19 October 2026.
