A scheduled window, announced before it starts — not an incident.
Not every time a part of Dohos is briefly unavailable is something going wrong. Sometimes it's something going right, on a deliberately chosen schedule — an update applied safely rather than never applied at all. This is where that second kind of event is announced, ahead of time.
Discovered versus chosen — a real, consequential difference.
An incident is discovered: something breaks, someone notices, and an account gets written up after the fact. A maintenance window runs the other direction entirely — it's chosen, scheduled, and announced before anything changes, precisely so nobody discovers it the hard way.
There's a real, concrete consequence to that distinction: a window announced ahead of time is treated as a named exception when the availability commitment is eventually measured, rather than counted the same way an unplanned outage would be.
A reader lands on this page for a fairly narrow reason: something looked slow or briefly unreachable, and the question is whether that was expected. A scheduled window currently active would show here — what it affects and when it's expected to end.
A scheduled window uses the same four channels described in full for status updates generally — email, RSS, text, and webhook — rather than a separate mechanism built just for maintenance. Anyone already set up to hear about an incident opening hears about a scheduled window the same way, through the same subscription, without signing up twice.
How far in advance a window gets announced isn't a fixed number stated anywhere — it depends on what's being changed and how much notice that specific change reasonably calls for. What holds regardless: the announcement always comes before the window starts, never as an explanation added afterward.
It names one system, not a vague “the product” — and it ends by saying plainly whether anything is expected of the reader. Most windows ask nothing of anyone, and the announcement says so instead of leaving that unstated.
Different systems, affected differently.
The voice line's fallback is described in full at reliability — the same mechanism, whether the reason a call couldn't be taken directly was something breaking or something deliberately, briefly paused for an update.
No maintenance window is currently scheduled. When one is, it appears here with the details described above, and stays part of the visible record afterward rather than disappearing once the window closes — the same permanence incident history applies to a resolved incident.
How is this different from an incident?
An incident is unplanned and discovered after something has already gone wrong. A maintenance window is chosen and announced before anything changes. Both get written up honestly, but they start from opposite directions.
Will a maintenance window ever cause real downtime for my restaurant?
It can briefly affect the specific system named in the announcement — that’s the entire reason it gets announced in advance. No percentage or duration figure is published for how much a given window is expected to affect anything, because none has been measured.
Do I need to do anything before a scheduled window?
Only if the announcement for that specific window says so — some windows have no visible effect at all beyond the system briefly being paused.
Can a scheduled window turn into an incident partway through?
If something doesn’t go the way it was expected to, that’s handled honestly — the entry gets updated to say so, and if it genuinely becomes an unplanned problem, it’s treated and recorded as the incident it’s actually become.
Open the line.
Tell us about your restaurant. We load your menu, you place a call, and you hear it answered yourself.