NTP Pool Outage History
6 incidents recorded over the last 365 days, 4 of them resolved. Durations are measured from when PulsAPI first saw the problem to when it cleared, which is usually longer than the vendor's own figure.
Every Recorded NTP Pool Incident
| Date | Incident | Duration | Status |
|---|---|---|---|
| Oct 18, 2026 | Postgres database migrationThis is done! Please report any trouble or errors you see. I have one more maintenance to do to the database storing the monitoring scores. The graphs will not update for a few hours while I do this, but the actual… | 6h 0m | Scheduled |
| Sep 11, 2026 | Missing metrics on statuspageDuring the incident today we also noticed (belatedly) that the status page metrics updater had been failing because the status page API key had expired, oops. | 0 min | Resolved |
| Sep 11, 2026 | Database troubleMySQL went down because our Ceph storage cluster filled up. That traces back to a Ceph security upgrade we'd just finished. The new version checks S3 upload signatures more strictly than before, and that exposed a bug… | 2h 22m | Resolved |
| Apr 26, 2026 | Infrastructure migrationThe scheduled maintenance has been completed. | 8h 0m | Scheduled |
| Mar 7, 2026 | Database troubleSystem has been migrated as part of the infrastructure migration. | 1205h 58m | Resolved |
| Mar 2, 2026 | Data API outageThe website (in particular the graphs) had a prolonged outage today. The graphs are back now, but will have some expected maintenance windows in the coming weeks related to the infrastructure migration (see… | -209 min | Resolved |
Hear about the next one while it is open
Everything above is a record written after the fact. We can email you when the next NTP Pool incident opens instead, at the point where knowing still changes what you do.
Free, no password, no card. Unsubscribe in one click.
How to Read This NTP Pool Incident Log
Each row is an incident PulsAPI observed, not a summary written afterwards. The duration is wall-clock time between the first failing check and the first clean one, so it includes the window before NTP Pool acknowledged anything. Vendor post-mortems typically measure from acknowledgement, which is why their numbers are usually shorter.
Incidents still open have no duration yet and are listed as ongoing rather than being given a running total. The archive covers the last 365 days; anything older has aged out of the window rather than never having happened.
The longest single NTP Pool outage in this window ran 50d 5h, against a mean recovery of 10d 4h. If you depend on NTP Pool in a customer-facing path, the longest figure is the one to design around. The mean is what happens on a normal bad day; the maximum is what happens on the worst one.