Skip to content

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

Alerts

The six backup and archive conditions that email you, who receives them, and where the line between what we tell you and what we handle sits.

Six conditions email you. Every one is about your backups or your archive chain, and every one describes a state in which a restore would not do what you expect.

This is the whole list, stated as a whole list, because a partial one would let you assume the rest.

What we alert you about

  • WAL archiving stalled
  • A gap in the WAL chain
  • No usable base backup
  • A restore verification that failed
  • A base backup whose own WAL range is incomplete
  • Recovery point exposure above the commitment

You get one email when a condition opens, not one per evaluation while it stays true.

An alert stays open until one of our staff closes it with a note, even after the condition has cleared, so a brief fault leaves a record. The same people are emailed when it closes. Do not read a later success as an alert that closed itself.

Maintenance notices are sent separately and are not part of this set.

Where alerts go

Email goes to the owners, administrators and developers of the organisation that holds the service, at verified addresses only. Billing members and viewers are not emailed about alerts.

Each alert on a service is also written to that service's Activity tab when it opens and when it closes.

Read them in the dashboard

  1. Open Alerts in the sidebar for everything wrong across your services, worst first.
  2. Or open a service and select its Alerts tab for that one service.

The service's Alerts tab has two panels: What we alert on, which is the six conditions above, and Rules.

What we handle without telling you

Host hardware faults, storage degradation, capacity headroom and platform-level errors are ours. They raise alerts in our staff console rather than in your inbox, and none of them emails you, even when one affects your service.

That division is deliberate. An alert you cannot act on is noise in your inbox and work in ours.

Severity 1 incidents

Directly affected customers are emailed about a Severity 1 incident, and a written report on every Severity 1 incident follows within five business days.

The six conditions above are about your backups. An outage that has nothing to do with your backups is written to you by a person.

What you will see

An email naming the service, the condition and when it opened. The same entry appears on the service's Activity tab, and the service shows in the Alerts list until the alert is closed with a note.

Watch your own storage

Measure your storage yourself:

sql
SELECT datname, pg_size_pretty(pg_database_size(datname))
FROM pg_database
WHERE NOT datistemplate
ORDER BY pg_database_size(datname) DESC;

Compare it against the storage your plan allocates, on plan limits. A full volume stops PostgreSQL writing, and it is the failure that is cheapest to see coming.

Troubleshooting

You received an alert you could not act on. Tell us. That is a defect in the alert, not in you.

A colleague did not get the email. Alerts go to owners, administrators and developers at verified addresses. Check their role and whether their address is verified, on Team.

An alert is still open and the problem is fixed. That is the design: a member of staff closes it with a note so the fault leaves a record.

You want an alert on something not in the six. Tell us what and why.

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