Playbook, developer tools company
The deploy window is at night and nobody is at a desk
The work this trade does out of hours is not accidental. Releases go out when traffic is low, migrations run overnight, and somebody on the other side of the world starts their day as your team finishes theirs. So an overnight message is rarely idle browsing. It is somebody mid change, and a documented answer at that moment is the difference between a deployment finishing and being rolled back.
Why this is not the general answer
The handling pattern for out of hours holds across every trade. What follows is the part that does not.
- The reader chose this hour deliberately, because the change window sits outside business hours, which means they are mid procedure rather than curious and a partial answer costs them the window.
- Documentation does not keep office hours, so overnight is when published material is at its most valuable, which is the reverse of every trade where the real answer is a person being awake.
- A customer's own monitoring frequently sees a degradation before a status page acknowledges one, so an overnight reader may be right about something nobody has confirmed, and the wording must not contradict them.
- Who gets woken is decided by a published severity definition and a support plan rather than by how urgent a message sounds, and stating that at two in the morning is kinder than implying somebody is reading.
How it arrives
- is anyone actually around right now
- we are mid deploy and calls are failing at 2am
- what counts as a severity one out of hours
- does our plan include overnight cover
- how do i raise something urgent outside your hours
- which timezone is your support team in
What has to be indexed for this to work
| Support hours, written with the timezone and what happens outside them | The actual coverage in a named timezone, and whether anything at all is monitored overnight. Somebody working a change window is calculating when a reply could realistically arrive, and a vague answer makes that calculation impossible. |
|---|---|
| The severity definitions and what each one triggers | What is serious enough to wake somebody, who may raise it and through which route. Vague urgency wording produces both failures at once: people who do not escalate a real outage, and people who escalate a question. |
| Rollback and recovery procedures | The material a reader genuinely needs at that hour, which is how to undo the thing they are halfway through. It is documented, it is stable, and it is answerable without anybody being awake to answer it. |
| The out of hours route, kept separate from the ordinary one | Where an urgent report goes overnight and what to put in it. If your plan does not include overnight cover, publish that, because a message left unanswered until morning is worse than a clear statement that nobody is reading. |
The reply
Nobody is reading messages here at this hour, so I would rather say what I can from the documentation than leave you waiting on a reply. Support hours and overnight coverage are set out with the timezone on that page, and the severity definitions there decide what can be raised outside them and by which route [1]. If you are mid deployment, the rollback procedure is documented step by step and does not depend on anybody being available [2]. If your own monitoring is showing failures, the status page is the live source and reporting what you are seeing there is the fastest path. Leave your name, your work email and what you are seeing, and it will be waiting first thing.
It says nobody is reading in the first sentence, because a message left to hope overnight is the worst outcome and this reader has decisions to make now. Pointing at the rollback is the one genuinely useful thing available at that hour. Acknowledging their monitoring rather than reassuring them keeps it honest, since they may well be seeing something real.
Where it stops
The trigger. The reader describes a live impact, asks for somebody to be woken, or asks whether their plan covers the situation they are in overnight.
I cannot reach anybody or raise anything, and I would rather say so than let this sit. The out of hours route is on the support page and is how somebody gets woken if your plan covers it. Leave your name, your work email and what you are seeing, and it will be there first thing.
It stops answering before it guesses, says who will pick it up, and asks for the one thing that makes a reply possible. Nothing about it reads as a dead end.
Never say this here
Out of bounds
- Never say somebody will look at this shortly, or that a message has been passed to an on call engineer.
- Never state support hours, response targets or overnight cover that are not published for the reader's plan.
- Never tell somebody their problem is not serious enough to escalate, since severity is defined in a document and judged by a person.
- Never assert that the service is healthy overnight, because nothing here observes it at any hour.
Questions
- Is a widget useful overnight if it cannot reach anybody?
- It is more useful overnight than during the day, because the alternative at three in the morning is nothing at all. A cited answer out of the rollback guide is worth a great deal to somebody mid change, and that is exactly what published material can give.
- Should we switch it off outside hours?
- Switching it off removes the answers along with the expectation. Wording the fallback so it states plainly that nobody is reading achieves the honesty without losing the documentation, and it is one sentence of work.
- Customers report problems before our status page does. How should it handle that?
- By not contradicting them. It has no view of the service, so it cannot say anything is fine. Pointing at the status page as the live source and taking the report is correct, and that is frequently how an incident gets confirmed.
Keep reading
- Everything for a developer tools companyOn a docs site an assistant competes with search, not a phone line. Version skew, deprecations and error strings decide whether it earns its place.
- Handling out of hours in generalThe difference between an emergency route and a message form, and why an honest wait time beats a promise you cannot keep.
- Most complaints here are technically specific and frequently correctDeprecation deadlines, a change that broke a build, and a reader who is usually right. Answering without conceding or arguing the technical point.
- Answering a pasted stack trace without ever seeing the projectDevelopers paste the error, not the concept. What an assistant can say about a failure it cannot reproduce, and where the guessing has to stop.
- Install, credential, first successful call, in the language they are writingQuickstart questions are narrow, repetitive and decide whether an evaluation continues. What to index per language so the answer lands.
Try it on your own material
Upload a document or point it at your site, paste one line of HTML, then ask it something only your business could answer.