The published limit
60 requests per minute, per client, unauthenticated. This is the figure in Terms §3, which makes anything above it presumptively unreasonable and reserves our right to throttle or block it. It is the number to design against.
"Client" means one program or one browser tab, not one network. If you run a dashboard on four screens, that is four clients.
What is actually enforced
Enforcement happens at the edge, keyed on source IP address, at 600 requests per minute with a burst of 120. That is ten times the published per-client limit, on purpose.
The reason is that an IP address is not a client. Behind carrier-grade NAT, an office, a university, or a school, one address can be hundreds of unrelated people. Metering that address at 60 would cut all of them off because of one of them, and this site's own pages are not cheap:
| Page | What it polls | Requests / min / tab |
|---|---|---|
/ | liveStats (2 calls / 15 s) + heroMap (1 call / 15 s) | ~12 |
/live | liveStats (2 calls / 15 s) + livePage (1 call / 30 s) | ~10 |
At 60 per IP, a shared network would start failing at five open tabs. So the enforced ceiling sits high enough that no plausible group of real readers reaches it, and low enough to stop a single scraper pulling thousands a minute.
The gap between the two numbers is not permission to use it. A client over 60 is over the limit whether or not it trips the ceiling, and the usual response is an email asking it to stop rather than a block that also lands on everyone sharing its exit address.
When you go over
You get 429 Too Many Requests with a Retry-After header. Honour it. Retrying a 429 immediately, or worse in a tight loop, is what turns a throttle into a block.
Repeated abuse, credential probing, and scanning are handled separately by the edge and result in an IP ban rather than a 429. Those bans are not on a timer.
Spending less
Most clients that hit a limit are polling something that did not change. Rough refresh rates worth knowing:
- Alerts change on the order of minutes. Polling
/alerts/*faster than every 30 seconds mostly returns what you already had. - The radar mosaic updates about every five minutes. The site checks every 30 seconds only to notice a new frame promptly; the tiles themselves are cached.
- Lightning is not an HTTP resource. Use the MQTT feed, which pushes flashes as they arrive. It costs one connection instead of a poll loop, and it is the only way to get them at full rate.
- Location search is for typeahead. Debounce it; do not send a request per keystroke.
Stop polling when nobody is looking. Both of this site's pages check document.hidden and skip the tick, because a backgrounded tab that polls forever is exactly the pattern that gets an API locked down for everyone.
MQTT
The public lightning broker has no request-per-minute limit, because it is a subscription rather than a poll. What it does have is a message rate: the full GOES-East disk runs around a thousand messages a minute and several times that during an outbreak. Subscribe to the geohash boxes you care about, not wxalerts/glm/v1/#. The MQTT docs explain the topic tree.
Keyed access
Nothing on the public API needs a key today. If and when keys are issued, their limits are set at issuance and governed by the API Terms of Use and Terms §20 rather than by this page.
Needing more
Ask. If you are building something that genuinely needs to poll harder, whether a research pull, a public display or an integration, say hello in Discord before you start rather than after you are blocked. Sustained unexplained traffic looks like an attack from this side, and it is treated as one.
Written requests and anything commercial: [email protected]. Commercial use needs permission first under Terms §3 regardless of request volume.