I build Overwatch (overwatch.confinia.io), an open-source control room that decodes and charts telemetry from the SatNOGS network. SatNOGS DB is where our telemetry and sat_id lookups come from, and we credit SatNOGS DB contributors (CC-BY-SA) on every page that shows it.
Since 2026-08-20 our requests from 5.135.143.93 stop at the network layer, and I would like to explain what we were doing rather than just ask to be let back in.
We had two bad patterns. A repair loop queried per-object endpoints every 120 seconds for satellites we could not resolve, retrying indefinitely; and resolve_sat_id queried /api/satellites/?norad_cat_id= once per satellite at every service start, so a failure meant asking again on the next restart. Neither had backoff or a give-up.
Both are fixed and deployed. We now read the full satellite list from one paginated bulk pass per day and answer every lookup from our own copy; per-object queries happen only if that bulk copy does not exist yet, with exponential backoff and a permanent give-up; and a 403 or 429 stops us entirely for hours rather than provoking a retry.
Two questions. Is 5.135.143.93 blocked on your side, and if so could it be lifted? And what request rate would you consider acceptable for a service like ours — I would rather size to your answer than to my own guess.
Thank you for SatNOGS; it is the reason this project exists at all.
Indeed your IP address has been blocked since 20th of August due to these requests you describe. As you have fixed these issues, I’m going to unblock it in the next hour.
For the satellites,
This is the best way to hit the api/satellites, get the whole list instead of querying each object, as the result is cached and not changed frequently.
Not sure I understand what you mean by this, but I don’t think you need an per object request as the information are the same with hitting and get the whole api/satellites list.
If any of these rates don’t make sense, we can discuss it and find a better solution.
In a general note, the last months we have seen a big increase from bots and (mostly ai generated) software scraping or using Network and DB, through API or Web pages. Unfortunately resources of LSF can not support this load and in order to keep the services up we need to limit the requests with different ways.
In the near future we are going to develop new limitations and maybe a permissions schema that will fix more permanently these issues. There will be an announcement for these change in order to present the logic behind the numbers and discuss them with the community and how we can make them fair and useful for anyone uses them.
You’re right about per-object queries: we now mirror the full /api/satellites/ list once a day and answer every lookup from our own copy.
On rate — we’d only paced our telemetry loop, and three other call sites bypassed it. That was the 429s. There’s now one global limiter in front of every SatNOGS call: one request per 11 seconds, whichever endpoint. Zero 429s since.
We also honour the 1/day limit for is_frequency_violator satellites; it’s in the bulk payload already, so it costs nothing.
Total footprint: one bulk pass a day, plus 23 satellites polled every 30 minutes, all behind that limiter. If that’s still too much, say so — it’s one number for us to change.
i love your work. cool bro! especially the groundstation. btw i notice your app only listed groundstations that send back telemetry from current 23 sat only. right? because i check not all gs listed.
Thanks! And you’re exactly right — it’s a by-product, not a station list. We only see a station when it hears one of the 23 satellites we track, so anything pointed elsewhere is invisible to us. 359 stations so far, purely from that overlap.
Making it station-centric rather than satellite-centric is the next thing I want to fix. 73!
@bali — the station-centric work you pointed at is underway. One question while I build it: when your station goes quiet, how do you work out whether it’s you or just nothing overhead?
That’s what I’m trying to answer automatically — compare a station against its own history, and against what other stations managed on the same passes. If you already have a way of doing it, I’d rather build on that than invent something.
Done — the popup now names the satellite, and the name opens its page. It was falling back to “the satellite” exactly on the station view, where every line is a different one. Lands with today’s release.
No bug on the SatNOGS side. METEOR M2-3 and M2-4 send LRPT images. The Network decodes those as images on observations. The DB carries telemetry frames, and these two do not produce any, so db.satnogs.org is right to show none.
The mistake was mine. Those two were added through the “add any satellite” picker, which gives position tracking for anything catalogued. Telemetry needs an open decoder, and these have none. My list still said “no frames yet”, which promised something that can never arrive. It now says “position only (no open decoder)”. That wording is what sent you digging.
On the OSCAR list: the picker already lets anyone add any catalogued satellite, so nothing is excluded by design. What decides whether telemetry shows up is simpler than an organisation: an open decoder, and frames heard recently. Most OSCAR birds are transponders with no telemetry decoder, so they would appear as position-only dots. If you know OSCARs, or school and educational satellites, that do have decoders and are being heard, name them and I will add them.
