~15.5 h outage on api.ambientweather.net /v1 tier, 2026-07-30/31 — 503 before authentication, up to 84% request failure

[highsierralabs]

Summary

The REST API application tier (api.ambientweather.net/v1/*) returned
intermittent HTTP 503 from approximately 2026-07-30 23:14 UTC to
2026-07-31 14:46 UTC (~15.5 hours). Failure rate reached 84%
sustained over 13 hours. The consumer website and other subdomains were
unaffected, and no status page or acknowledgement existed anywhere I could
find, so I'm filing the observation here.

I run an automated station poller at a fixed 1 request / 60 s (well under
the documented 1 req/s budget), which gave a continuous measurement of the
outage. Details below in case they're useful to ops.

Reproducer (no credential required)

During the outage, an unauthenticated request reproduced the failure:

GET https://api.ambientweather.net/v1/devices
→ HTTP 503 (nginx "Service Temporarily Unavailable" page)

A healthy tier answers this request with 401 Unauthorized — the 503
occurred before credential evaluation, so it is independent of any API
key, application key, or account. Verified both ways: 12/12 keyless
requests → 503 during a failing phase (~13:07–13:16 UTC); 10/10 keyless
requests → 401 during a healthy phase (13:18:25–13:18:37 UTC).

Fault localization

Concurrent controls at 2026-07-31 13:18 UTC:

Endpoint	Result
https://api.ambientweather.net/ (hostname root)	200
https://ambientweather.net/	200
https://lightning.ambientweather.net/	200
https://api.ambientweather.net/v1/*	503 (when failing)

• Cloudflare edge answered every request (CF-RAY present on all
  responses, including failures); the 503 body is a stock nginx error
  page from behind the edge. Edge/DNS/TLS all healthy.
• 503s returned fast (~0.1 s) — not timeouts.
• No Retry-After or X-RateLimit-* headers on any 503, and the
  documented throttling response is 429 — this was not rate limiting.
• Station data itself was unaffected: successful polls returned dateutc
  values current to within minutes throughout.

Timeline and failure structure

• Onset: discrete, ~23:14 UTC 2026-07-30 (prior 23 h background loss:
  ~0.35%).
• 2026-07-30 23:14–23:54: 31 of 41 polls lost (~76%).
• 2026-07-31 00:00–13:19: 675 of 800 polls lost (84.4%); 93 gaps

  150 s; longest continuous failure 56.3 min (02:29–03:25 UTC).

• Recovery: ~14:46 UTC 2026-07-31; clean 60 s cadence since.

One pattern that may help diagnosis: failure-run durations clustered
heavily on exactly 4 or 5 consecutive failed polls (300 s / 360 s
gaps — 62 of 93 gaps), i.e. a regular ~5–6 min cycle of one success then
several failures. From outside this looks like a periodic mechanism (a
health-check interval, cache TTL, or load-balancer rotation returning a
backend to service) rather than random overload — offered as an observed
signature only; I can't see your infrastructure.

Questions

1. Can you confirm the outage and cause?
2. Is there a status or notification channel for api.ambientweather.net
   availability? Third-party monitors track the consumer website only, so
   API outages are currently invisible to users.

Happy to provide raw probe logs (timestamps, headers, CF-RAY IDs) on
request.