Status

Service status

The address API is operational.Checked from this server when this page loaded in 21 ms · serving G-NAF release 2026-08.

Availability

100.00%

Availability of the /v1 API across the time we observed it, since 3 Aug 2026. We checked 99% of that period.

5 Aug 20262 Nov 2026
Operational (99.9%+) Degraded (99.5–99.9%) Below commitment Not measured

Every day, as a table

The same figures, for anyone who cannot use the chart above.

DateAvailabilityStateMonitoring coverage
2 Nov 2026100.00%Operational100%
1 Nov 2026100.00%Operational100%
31 Oct 2026100.00%Operational100%
30 Oct 2026100.00%Operational100%
29 Oct 2026100.00%Operational100%
28 Oct 2026100.00%Operational100%
27 Oct 2026100.00%Operational100%
26 Oct 2026100.00%Operational100%
25 Oct 2026100.00%Operational100%
24 Oct 2026100.00%Operational100%
23 Oct 2026100.00%Operational100%
22 Oct 2026100.00%Operational100%
21 Oct 2026100.00%Operational100%
20 Oct 2026100.00%Operational100%
19 Oct 2026100.00%Operational100%
18 Oct 2026100.00%Operational100%
17 Oct 2026100.00%Operational100%
16 Oct 2026100.00%Operational100%
15 Oct 2026100.00%Operational100%
14 Oct 2026100.00%Operational100%
13 Oct 2026100.00%Operational100%
12 Oct 2026100.00%Operational100%
11 Oct 2026100.00%Operational100%
10 Oct 2026100.00%Operational100%
9 Oct 2026100.00%Operational100%
8 Oct 2026100.00%Operational100%
7 Oct 2026100.00%Operational100%
6 Oct 2026100.00%Operational100%
5 Oct 2026100.00%Operational100%
4 Oct 2026100.00%Operational96%
3 Oct 2026100.00%Operational100%
2 Oct 2026100.00%Operational100%
1 Oct 2026100.00%Operational100%
30 Sept 2026100.00%Operational100%
29 Sept 2026100.00%Operational100%
28 Sept 2026100.00%Operational100%
27 Sept 2026100.00%Operational100%
26 Sept 2026100.00%Operational100%
25 Sept 2026100.00%Operational100%
24 Sept 2026100.00%Operational100%
23 Sept 2026100.00%Operational100%
22 Sept 2026100.00%Operational100%
21 Sept 2026100.00%Operational100%
20 Sept 2026100.00%Operational100%
19 Sept 2026100.00%Operational100%
18 Sept 2026100.00%Operational100%
17 Sept 2026100.00%Operational100%
16 Sept 2026100.00%Operational100%
15 Sept 2026100.00%Operational100%
14 Sept 2026100.00%Operational100%
13 Sept 2026100.00%Operational100%
12 Sept 2026100.00%Operational100%
11 Sept 2026100.00%Operational100%
10 Sept 2026100.00%Operational100%
9 Sept 2026100.00%Operational100%
8 Sept 2026100.00%Operational100%
7 Sept 2026100.00%Operational100%
6 Sept 2026100.00%Operational100%
5 Sept 2026100.00%Operational100%
4 Sept 2026100.00%Operational100%
3 Sept 2026100.00%Operational100%
2 Sept 2026100.00%Operational100%
1 Sept 2026100.00%Operational100%
31 Aug 2026100.00%Operational100%
30 Aug 2026100.00%Operational100%
29 Aug 2026100.00%Operational100%
28 Aug 2026100.00%Operational100%
27 Aug 2026100.00%Operational100%
26 Aug 2026100.00%Operational100%
25 Aug 2026100.00%Operational100%
24 Aug 2026100.00%Operational100%
23 Aug 2026100.00%Operational97%
22 Aug 2026100.00%Operational100%
21 Aug 2026100.00%Operational100%
20 Aug 2026100.00%Operational100%
19 Aug 2026100.00%Operational100%
18 Aug 2026100.00%Operational100%
17 Aug 2026100.00%Operational100%
16 Aug 2026100.00%Operational100%
15 Aug 2026100.00%Operational100%
14 Aug 2026100.00%Operational97%
13 Aug 2026100.00%Operational100%
12 Aug 2026100.00%Operational100%
11 Aug 2026100.00%Operational100%
10 Aug 2026100.00%Operational100%
9 Aug 2026100.00%Operational100%
8 Aug 2026100.00%Operational100%
7 Aug 2026100.00%Operational60%
6 Aug 2026100.00%Operational100%
5 Aug 2026100.00%Operational100%

How this is measured

A server in Melbourne checks the address API and the website every minute. It reaches them through public DNS, the same way a customer’s software does, so the figures include the automatic switch between our Sydney and Melbourne servers for the API. A check counts as available when the address answers with a normal success or redirect response. It does not test searches. Because the checking server is separate from the Sydney primary, it can see Sydney go down. An interruption shorter than a minute can fall between two checks.

Until 19 October 2026 the record came from a different monitor that ran roughly once an hour, so earlier days have far fewer checks. The Melbourne server’s own log goes back to 14 August 2026, and those minute-by-minute results were added to the record for the days it covers. Before 14 August, days were measured only by the hourly GitHub monitor.

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 minute-by-minute checks are more than five minutes apart, we do not know what happened in between. That time is counted neither way. It is left out of the figure and shown as reduced coverage instead. The older hourly records use a longer limit of five hours.

What this does not cover: if the Melbourne server itself is down, or cannot reach the website to save its results, nothing is recorded for that time. If the website is down at the same moment, the result cannot be saved either. While the website’s own name points at Melbourne during a switch, the checks would be Melbourne checking itself, so those minutes are not recorded. The API has its own switch to Melbourne. While that is in effect, the API check is also Melbourne checking itself, so the API is not recorded for that time. In every case the time shows as lost coverage, not as downtime, because a status page cannot prove its own total outage. Coverage is the figure that shows those periods.

Days are Australian Eastern time. The chart shows state, not height, because availability sits between 99% and 100% and a bar chart would show no visible difference. The exact figure for every day is in the table.

This is not the SLA calculation. Our Service Level Agreement is measured per calendar month, excludes announced maintenance and several other categories, and defines unavailability as five consecutive minutes of failure. The figure on this page excludes nothing, so it is the harsher of the two. It is not the basis of a service credit claim.

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 we announce it anyway.

Something wrong that this page does not show? support@wattleaddr.com.au