When a service goes down, forty people ask about it. Answered individually, that is forty chances to say something slightly different, forty estimates nobody can keep, and a desk fully occupied by a problem it is not fixing. One status entry handles all of it, and the wording matters more than the channel.
TL;DR
- A known issue answered forty separate times produces forty slightly different stories, and whichever one is most alarming becomes the company’s understanding.
- Publish the entry before you understand the cause. Waiting until you can explain it is what makes the comms late every time.
- Four fields carry the whole thing: what is affected, what to do meanwhile, when you will next say something, and whether you need reports.
- The next-update time is the most important field and the one most often omitted, because it is the only thing that stops people asking again.
- Tell people explicitly to stop raising tickets for it, or they will keep doing so politely and your queue stays unreadable.
- An automated agent only helps if the entry is machine-readable in the same place it reads everything else, not pinned in a chat channel.
Why forty individual answers go wrong
Each answer is written by a different person at a different point in the incident, with different information. The first says it is being looked at. The fourth says it should be back shortly. The twelfth, written by somebody who has just heard a rumour about the cause, says it is a problem with the provider.
Those answers get compared. People forward them, screenshot them, mention them in meetings, and the version that spreads is the one that sounds most serious. By the afternoon the organisation believes something nobody on the desk actually said.
The second cost is attention. A desk answering forty contacts about one incident has no capacity for the tickets that are not about it, so an incident affecting one service degrades support for everything else. That is invisible in the metrics and obvious to anybody who needed help that afternoon.
Publish before you understand it
The reason status entries go out late is that people wait until they can explain the cause. That is the wrong threshold. You can publish a useful entry within four minutes of confirming the symptom, and the cause is not one of the fields that helps anybody.
What the reader needs is whether this affects them, what to do in the meantime, and when they will hear more. None of that requires a diagnosis. A first entry saying the service is unavailable, we are investigating, next update at a stated time is complete by every measure that matters to the person reading it.
So separate the two jobs. Diagnosis belongs to whoever is fixing it. Communication belongs to somebody else, starting immediately, and the fix will be no slower for it.
The four fields
| Field | Why it earns its place |
| What is affected, in user terms | Name the thing people use, not the system that broke |
| What to do meanwhile | Converts a notice into help, even if the answer is wait |
| Next update time | The only field that stops people asking again |
| Whether to report instances | Prevents forty tickets, or gets you the ones you need |
| Start time | Lets somebody tell this from an unrelated problem |
| Cause | Optional, and usually unhelpful to the reader |
The first row fails more often than any other. An entry about a failed authentication service means nothing to somebody who knows only that they cannot log in to the expenses tool, so name the symptom and the tools affected rather than the component.
The fourth row is the one teams forget to state either way. People raise a ticket because they assume you might not know, so say explicitly that you do know and no ticket is needed, or say that you want reports and what to include. Silence produces the polite version of forty tickets.
The next-update promise
Give a time for the next update and then meet it, including when nothing has changed. An update saying no change, investigating, next update in an hour is a real update, and skipping it because there is nothing to report is how a status page loses its audience.
Avoid estimating restoration. An estimate is a promise with no information behind it in the first hour of an incident, and missing it costs more than never giving one. The next-update time is a commitment you control completely, which is exactly why it works.
What to do:
- Publish within minutes of confirming the symptom, with the cause field empty if that is where you are.
- Name what people use rather than what broke, and list the visible tools affected.
- Give a next-update time and meet it even when the update is that nothing changed.
- State plainly whether to raise tickets, in one sentence, rather than leaving it implied.
- Put the entry where the agent reads its other content, not only in a chat channel or on a status page nobody has bookmarked.
- Close it explicitly when resolved, because an open entry people have stopped trusting is worse than none.
Making the agent use it
An automated agent can take the whole forty-contact wave off the desk, and only if the entry is somewhere it reads. A notice pinned in a chat channel is invisible to it, which is how teams end up with an agent cheerfully troubleshooting a service that is known to be down.
Put active known issues in the same content source the agent reads for everything else, and make the removal as deliberate as the publishing. A stale known-issue entry is the worst failure in this topic: the agent tells people a service is down for the rest of the week because nobody closed it.
Disclosure: Matram is owned by the same people who publish PeopleOpsHQ. It is relevant here because it answers from the content sources you point it at, so a known-issue entry added to one of those gets picked up alongside everything else, and it is priced flat at $29, $69 and $199 a month with unlimited seats, which suits an incident where the whole company asks at once. It has no free tier, it answers questions rather than actioning tickets, and it is not an ITSM platform, so incident management itself stays wherever you run it. The options are compared in our IT support chatbot comparison.
Final thoughts
Answering a known issue individually is the default because it feels responsive, and it produces an inconsistent story, a saturated desk and an organisation that believes something nobody said.
Publish within minutes using four fields, name the symptom rather than the component, promise a next update rather than a restoration time, and say outright whether you want tickets. Then put the entry where your agent can read it and close it as deliberately as you opened it.
Frequently asked questions
Why not just answer each person about a known issue?
Because forty separate answers written by different people at different points in an incident produce forty slightly different stories, and the version that spreads is whichever sounds most serious. The second cost is attention: a desk occupied by forty contacts about one outage cannot handle the tickets that are not about it, which degrades support for everything else and shows up in no metric.
When should you publish a known issue entry?
Within minutes of confirming the symptom, with the cause field empty if that is all you have. Teams publish late because they wait until they can explain what happened, which is the wrong threshold, since the reader needs to know whether it affects them, what to do meanwhile and when they will hear more, none of which requires a diagnosis.
What should a known issue notice contain?
What is affected in user terms, what to do in the meantime, the time of the next update, whether to raise tickets, and the start time so people can distinguish this from an unrelated problem. The cause is optional and usually unhelpful, while naming the component that broke instead of the tools people actually use is the commonest reason an otherwise good notice helps nobody.
Should you estimate when service will be restored?
Avoid it, especially in the first hour, because an estimate is a promise with no information behind it and missing it costs more than never offering one. Commit to a next-update time instead, which is entirely within your control, and meet it even when the only update is that nothing has changed, since skipping a no-change update is how a status channel loses its audience.
How do you stop people raising tickets for a known issue?
Tell them explicitly, in one sentence, that you are aware and no ticket is needed, or say that you do want reports and what to include. People raise tickets because they assume you might not know, so silence on this point produces the polite version of forty duplicates, and leaving it implied is not the same as saying it.
Where should the known issue entry live?
In the same content source your automated agent reads for everything else, not only pinned in a chat channel where the agent cannot see it, which is how a deployment ends up troubleshooting a service everybody knows is down. Make closing the entry as deliberate as publishing it, because an agent telling people a service is unavailable days after it recovered is the worst outcome in this whole topic.
