Skip to content

Matches page titles and page text. Forty pages, indexed at build time.

Maintenance windows

The weekly window assigned to each service, the notice we give before planned work, and what happens if we overrun.

Every service has a weekly maintenance window: a recurring period in which planned work with expected impact may run. It is assigned when the service is created.

Planned work is announced at least 72 hours ahead, and the announcement rather than the window is what the notice period and the availability exclusion are measured against.

Find your window

  1. Open the service.
  2. Select the Configuration tab.
  3. The maintenance window is shown there, in UTC.

Times are UTC so a daylight-saving change cannot move the window without telling you.

Each service is assigned the same window: Sunday, starting at 02:00 UTC, four hours long.

Notice

Anything with expected impact is announced at least 72 hours ahead. The platform refuses to record an announcement with less notice unless it is marked as an emergency.

The notice is emailed to every active member of each organisation with an affected service, and it lists only that organisation's services. It states the time in UTC, the expected duration, the reason, the expected impact, and how many hours of notice it gives.

What runs in a window

Planned work that needs a restart or has other expected impact:

  • Minor PostgreSQL version updates
  • Operating system and kernel updates on the host
  • A restart that brings in a configuration change which needs one

A plan change does not wait for the window. It runs when you confirm it, restart included. See scaling.

Overrunning counts against us

If maintenance overruns the announced duration, the excess counts as unplanned downtime against the availability commitment. An unbounded maintenance window would make that commitment meaningless.

The exclusion covers only work that was announced, and only inside the start and duration the announcement gave. An outage nobody announced is an outage, whoever caused it.

Emergency maintenance

Emergency maintenance is permitted for four reasons only:

  1. An actively exploited security vulnerability
  2. Hardware showing signs of failure
  3. A risk to data integrity
  4. An emergency at our provider

It gets as much notice as the situation allows, and the notice says that it is short notice and why.

Every emergency owes the affected customers a written explanation within five business days. The platform records that deadline when the emergency is announced.

What you will see

An announcement arrives by email at the verified address of every active member of an affected organisation. It names the service or services, the start in UTC, the expected duration, the reason, the expected impact and the notice given.

During the work, a restart looks to a client exactly like a dropped connection. Clients with retry logic reconnect; clients without it report an error.

Troubleshooting

Your application dropped connections at a time you did not expect. Check the Activity tab for the service. A plan change, a restore and an emergency all run outside the weekly window.

You did not receive an announcement. Notices go to active members at verified addresses. An unverified address receives nothing. Check the member list on Team.

The window is inconvenient. Tell us which service and what would suit you.

Contact support any time by email or from your dashboard. Every service is monitored around the clock.