Copy a maintenance-window announcement template that keeps timezone, scope and status history verifiable.
Oct 29, 2026
Copy a maintenance-window announcement template that keeps timezone, scope and status history verifiable.
Oct 29, 2026
Copy a maintenance-window announcement template that keeps timezone, scope and status history verifiable.
Oct 29, 2026
A reusable structure for maintenance window announcements, built from a verified Coinbase status notice with clear status labels, timing, and a worked example.
Oct 29, 2026
What this checklist adds
This midday update restates the verification steps for operators checking primary sources before repeating a claim. It is a separate checklist from earlier posts on this site.
The useful answer up front: a maintenance window announcement works best when it separates four things into distinct, separately dated blocks — scheduled window, impact during the window, verification stage, and completion. The Coinbase status notice for October 24, 2026 shows each of those stages in one page, which makes it a practical model to copy structurally rather than textually.
What the source notice shows
Coinbase scheduled the maintenance on Oct 22, 16:20 PDT: system maintenance on October 24, 2026, from 10:00 AM to 10:30 AM ET (7:00 AM to 7:30 AM PT). That is the announcement stage, filed before anything happened.
At 07:02 PDT on October 24 the notice moved to an In progress entry: the scheduled maintenance is currently underway. The stated impact was narrow — sends and receives of Bitcoin (BTC), Litecoin (LTC), Bitcoin Cash (BCH), Zcash (ZEC), Dash (DASH), and Ethereum (ETH) and ERC-20 tokens on the Ethereum and Ethereum Classic networks may be delayed, and you may not be able to create a new address to receive these assets until the maintenance is complete. Buying, selling, and trading are not impacted.
At 08:05 PDT on October 24 the notice shows a Verifying entry and a Completed entry, both timestamped 08:05 PDT; the final update confirms sends and receives are fully operational and new receiving addresses can be created again. Note the timing gap between the scheduled 7:00 AM to 7:30 AM PT window and the later timestamps — the notice does not explain it, and a template should not paper over such gaps.
Stage labels to keep separate
| Label | What it means | Source example |
|---|---|---|
| Scheduled | Announced in advance; nothing has started. | Oct 22, 16:20 PDT entry |
| In progress | Work is underway; impact language applies. | Oct 24, 07:02 PDT entry |
| Verifying | Checks running; do not yet claim restored service. | Oct 24, 08:05 PDT Verifying entry |
| Completed | Service confirmed operational. | Oct 24, 08:05 PDT Completed entry |
A common mistake is collapsing Verifying and Completed into one sentence. If both are timestamped the same minute, present them as two entries rather than asserting an order the timestamps do not prove.
Worked template example (hypothetical)
A hypothetical example, using only labels and structure from the source, shows how the blocks fit together:
- Scheduled window: state the date, the start and end times, and both time zones exactly as the source does (for example, 10:00 AM to 10:30 AM ET / 7:00 AM to 7:30 AM PT).
- Affected assets: list each ticker as written, not paraphrased.
- What users may see: delayed sends and receives; inability to create a new receiving address until completion.
- What is unaffected: buying, selling, and trading.
- Progress entry: timestamp, In progress label, restate the impact.
- Verifying entry: timestamp, Verifying label, no restoration claim.
- Completed entry: timestamp, Completed label, confirm sends and receives are fully operational and that new receiving addresses can be created.
In the source case, the scheduled window ran 10:00 AM to 10:30 AM ET. The In progress entry is stamped 07:02 PDT and the Verifying and Completed entries are stamped 08:05 PDT. Those are the only timestamps the notice provides; any statement about how long the work actually took beyond them would be inference, not record.
A short editing checklist
- Does every entry carry a date and time zone?
- Are announcement, progress, verification, and completion on separate lines?
- Is the unaffected-services line explicit?
- Are asset tickers reproduced exactly?
- Does the completion entry confirm both sends and receives and new receiving addresses?
- Have you removed any implied sequence that timestamps do not support?
What the source does not say
- It does not explain why the In progress and Completed entries fall outside the announced 10:00 AM to 10:30 AM ET window.
- It does not specify a cause, a responsible team, or a root-cause follow-up.
- It does not say whether any other assets or products were affected beyond the listed networks.
- It does not state user-side remedies or compensation.
- It does not establish an order between the Verifying and Completed entries, which share a timestamp.
- It does not provide a schedule for future maintenance windows or a post-incident review.
Used this way, the template keeps announcements precise about status and honest about what is not yet known.