Service status
Availability
Availability of the /v1 API across the time we observed it, since 3 Aug 2026 (47 days so far). We checked 82% of that period.
8 days were checked for less than half their length. Those hours are left out of the figure above rather than guessed at — see the method below.
Every day, as a table
The same figures, for anyone who cannot use the chart above.
| Date | Availability | State | Monitoring coverage |
|---|---|---|---|
| 18 Sept 2026 | 100.00% | Operational | 86% |
| 17 Sept 2026 | 100.00% | Operational | 100% |
| 16 Sept 2026 | 100.00% | Operational | 56% |
| 15 Sept 2026 | 100.00% | Operational | 82% |
| 14 Sept 2026 | 100.00% | Operational | 46% |
| 13 Sept 2026 | 100.00% | Operational | 55% |
| 12 Sept 2026 | 100.00% | Operational | 100% |
| 11 Sept 2026 | 100.00% | Operational | 100% |
| 10 Sept 2026 | 100.00% | Operational | 100% |
| 9 Sept 2026 | 100.00% | Operational | 100% |
| 8 Sept 2026 | 100.00% | Operational | 95% |
| 7 Sept 2026 | 100.00% | Operational | 60% |
| 6 Sept 2026 | 100.00% | Operational | 100% |
| 5 Sept 2026 | 100.00% | Operational | 100% |
| 4 Sept 2026 | 100.00% | Operational | 78% |
| 3 Sept 2026 | 100.00% | Operational | 100% |
| 2 Sept 2026 | 100.00% | Operational | 100% |
| 1 Sept 2026 | 100.00% | Operational | 33% |
| 31 Aug 2026 | 100.00% | Operational | 43% |
| 30 Aug 2026 | 100.00% | Operational | 54% |
| 29 Aug 2026 | 100.00% | Operational | 15% |
| 28 Aug 2026 | — | Not measured | 0% |
| 27 Aug 2026 | 100.00% | Operational | 39% |
| 26 Aug 2026 | 100.00% | Operational | 100% |
| 25 Aug 2026 | 100.00% | Operational | 100% |
| 24 Aug 2026 | 100.00% | Operational | 9% |
| 23 Aug 2026 | 100.00% | Operational | 50% |
| 22 Aug 2026 | 100.00% | Operational | 100% |
| 21 Aug 2026 | 100.00% | Operational | 100% |
| 20 Aug 2026 | 100.00% | Operational | 100% |
| 19 Aug 2026 | 100.00% | Operational | 100% |
| 18 Aug 2026 | 100.00% | Operational | 100% |
| 17 Aug 2026 | 100.00% | Operational | 100% |
| 16 Aug 2026 | 100.00% | Operational | 100% |
| 15 Aug 2026 | 100.00% | Operational | 100% |
| 14 Aug 2026 | 100.00% | Operational | 100% |
| 13 Aug 2026 | 100.00% | Operational | 100% |
| 12 Aug 2026 | 100.00% | Operational | 100% |
| 11 Aug 2026 | 100.00% | Operational | 100% |
| 10 Aug 2026 | 100.00% | Operational | 100% |
| 9 Aug 2026 | 100.00% | Operational | 100% |
| 8 Aug 2026 | 100.00% | Operational | 100% |
| 7 Aug 2026 | 100.00% | Operational | 60% |
| 6 Aug 2026 | 100.00% | Operational | 100% |
| 5 Aug 2026 | 100.00% | Operational | 100% |
| 4 Aug 2026 | 100.00% | Operational | 100% |
| 3 Aug 2026 | 100.00% | Operational | 100% |
How this is measured
The API is checked from outside our infrastructure — deliberately not from the servers being measured, because a monitor running on a machine cannot report that machine going dark. Checks run roughly hourly, so a very short interruption can pass between two of them; the coverage figure below says how much of each day we actually observed.
Each check states the service’s condition at that instant, and the time until the next check is credited to it. Availability is the share of the time we observed that was available. Where two checks are more than a few hours apart we do not know what happened in between, so that time is counted neither way — it is left out of the figure and shown as reduced coverage instead. Guessing in either direction would be a fabrication: one invents uptime, the other invents an outage.
If the API fails while the rest of the site is up, the check records the failure and it counts against us. A failure of everything takes the recorder down with it and leaves a gap, which shows as lost coverage rather than as downtime — no status page hosted on its own infrastructure can report its own total outage, and we would rather say that than imply the number covers it. Coverage is the figure that reveals those periods.
Days are Australian Eastern time. The chart shows state rather than height because availability sits between 99% and 100%, where a bar chart would show nothing a reader could see; the exact figure for every day is in the table.
Planned maintenance
Our maintenance window is Sundays 01:00–05:00 Australian Eastern time. Work that could interrupt the API is scheduled inside it wherever possible, and Enterprise customers are notified by email at least 48 hours beforehand. The quarterly G-NAF dataset refresh runs inside this window; it is designed to swap the index in place without downtime, and is announced regardless.
Something wrong that this page does not show? support@wattleaddr.com.au