Create agents that monitor airspace activity 24/7 - military aircraft in a region, private or government jets, a GPS-jamming spike, or a travelling friend or family member - and get alerts the moment something relevant happens. Or just ask anything about what's flying right now. Powered by our own independent network of 5,600+ antennas across 120 countries. No code, no data engineering, no terabytes to store.
OtariControl Your LLM Infrastructure
Maker
Hey Product Hunt 👋
I'm Alex, co-founder of Wingbits.
For the last two years we've built a completely new flight tracking network: 6000 antennas across 120 countries, generating terabytes of data daily, with Spire Global and Korean Air as customers. Until now, gaining insights from this data required a data science team. Now we're launching Wingbits.ai so everyone else can easily get answers too.
It's made for reporters, prediction markets, competitive analysts, route planners, aviation enthusiasts. Anyone can extract geopolitical or operational insights by just asking in plain English.
No code, no data processing, no infrastructure.
A few things you can do today:
Ask "where is Air Force One right now?" and get a live map link to track it
"Which private jets visited Davos last weekend?" or "Mar-a-Lago last Saturday?"
Spin up agents that send alerts to Slack, email, Telegram, or Teams the moment something matches your criteria
Compare GPS jamming events across regions, or
Get scheduled reports or analysis on things like competitor routes
PH community gets a free tier, or 1 month of Pro free with code HUNTERS.
Let me know - what's one thing you've always wanted to know about aviation, but never had the tools for?
— Alex
Report
@lungu The aggregation problem at this scale is what I'm most curious about. 6000 antennas + terabytes daily means you can't be query-time aggregating raw ADS-B, but the use cases listed (live tracking, scheduled reports, alerts) span very different latency/precompute profiles. Are the precomputed materializations decided per-use-case or do you have one canonical signal layer everything queries off?
Also, is there an MCP server on the roadmap? Ask-the-sky from a Claude or Cursor agent feels like a natural fit.
Report
Maker
@arturbrugeman yes sir! We try to identify the most common query patterns and aggregate the relevant data. It would very hard to aggregate ADS-B at query time, especially over longer time windows.
The MCP will be released really soon as well. Would you like to be a beta tester?
Report
@lungu Hi Alex, Congrats on the launch. FlightRadar24 is my mental reference point, but that's largely an aggregated network, whereas you've built your own antennas. I can see from the thread the agents sit on top of your existing data stack, so is the real moat the network itself (coverage, the GPS-jamming data others can't get), or the agent layer that makes it all askable?
Report
Maker
@michael_zorez thanks, and great question! Honestly, it’s both, and they reinforce each other. The network is the hard part to replicate and the core of both our businesses. Our differentiation is that we reward our data providers based on performance, whereas FlightRadar24 contributors only get the paywall and ads removed. Because of that incentive, we get better data than they do.
But even more importantly, it’s more secure. It’s much harder to spoof data on Wingbits, and doing so can cost you your station. On FR24 anyone can spoof, which makes it pretty scary to build an autonomy layer on top of that data. Our agentic layer is the interface that makes everything the network collects accessible in plain English.
Report
@lungu didn‘t expect that incentive structure, but makes sense that the network and the agent layer compound. Thanks for the thorough answer. And continued good luck!
Report
@lungu You're hitting on exactly what makes this domain tricky. We're using ADS-B Exchange as our primary feed but with custom enrichment layers on top to catch edge cases raw Mode S misses. For deduplication, we lean on temporal windowing plus a state machine that treats rapid-fire geofence hits as a single event burst rather than cascading alerts—basically consuming the event stream into a short-lived buffer before deciding what actually matters.
Report
Real-time ADS-B data processing at scale is genuinely hard. The fan-out problem for alert subscriptions when flight state changes happen fast is nontrivial. We've wrestled with similar event-driven architectures for customer health signals where latency matters. Are you processing raw Mode S data directly or using a provider like ADS-B Exchange? How do you handle alert deduplication when a flight triggers multiple geofence conditions simultaneously?
Report
Maker
@anand_thakkar1 we know the pain! Before wingbits.ai we built wingbits.com, a global network of stations collecting data from around the world (check the map). One of our main products is a real-time stream that ingests 3TB of data daily and outputs clean, processed events to our customers with under 1s latency. Low latency is critical for some of our aviation customers, and that’s why we want control over the full stack.
On your second question, that’s something we’re still working on. During the beta we included some basic checks, but it’s an area we’re actively improving.
What did you land on for your fan-out problem? Always keen to compare notes.
Report
Building AI agents on top of live ADS-B data feeds is genuinely tricky since the message stream is noisy with duplicate transponder IDs and position errors. We've worked with high-frequency event streams in our own infrastructure and know how hard accurate state reconciliation can get. What's your approach to deduplicating transponder messages and handling geofence evaluation latency when multiple flights trigger alerts simultaneously?
Report
Maker
@retain_dev it’s challenging for sure! Wingbits.ai is built on top of our existing stack of data products. Before wingbits.ai we built a global network of stations (wingbits.com/map) and a real-time stream that ingests ~3TB of data daily. We deduplicate and clean the raw messages there, and the agents only ever query clean data.
Report
The alert agents are the most interesting part for me. Most people don't need all the raw flight data, they need to know when something unusual happens. How do you filter signal from noise when tracking things lie route changes or GPS jamming events?
Report
Maker
Thanks @ada_johnsen! It depends on the use case, of course, but I agree, the alerts are one of the most powerful features. Route changes are actually easy to detect but hard to interpret, since a deviation can happen for many reasons: disruptions, weather, or just unusual events. That's why we're working on integrating other data sources, like NOTAMs and weather alerts, to add the context that tells you whether a change actually matters.
GPS jamming is more straightforward, since the data is tagged with quality and certainty parameters. So we can check whether a reading is highly uncertain (as reported by the aircraft) and whether it's in an area known to be affected, like near conflict zones.
Report
Maker
@ada_johnsen building on what Alex said, the context layer is a part we're quite excited about. Raw deviation alerts are easy to generate but exhausting to act on, because most flight path changes are mundane (weather, ATC reroutes). What we keep hearing from the newsrooms and analysts testing the platform is that they want fewer, smarter alerts that come pre-contextualised, not more raw data.
On GPS jamming specifically - the daily aggregated view at wingbits.com/gps-jamming has been a really useful reference point for journalists covering the Baltic and Middle East. This was even covered in The Independent: https://www.independent.co.uk/news/world/middle-east/gps-jamming-spoofing-iran-us-israel-war-b2938167.html
Curious what you'd want to monitor - maybe we can spin up a test agent for whatever's interesting to you?
Report
@lungu Real-time monitoring is one of the cleaner use cases for agents because the signal and response window are clear. The hard part is making sure alerts stay useful instead of becoming another stream of noise.
Report
Maker
@alpertayfurr true! Alert fatigue can be a real problem. We let users set both the cadence of the evaluation and the time windows for the data sample, which helps a lot if configured right. The agents also have access to the history of alerts and can decide whether enough has changed to be worth flagging.
What kind of activity would you want to keep an eye on?
Thanks a lot for the feedback!
Report
@lungu That makes sense — using alert history to decide if something has meaningfully changed is a strong filter. I’d probably want to monitor pattern shifts rather than every single event: unusual route behavior, repeated delays, sudden volume changes, or anything that suggests a normal baseline has changed enough to deserve attention.
Report
Maker
@alpertayfurr Alert fatigue is for sure a consideration. We think about it like this: an alert that doesn't change your behaviour is just noise with extra steps (lol). So the agents are designed to provide fewer, higher-confidence pings rather than annoying you with every minor anomaly.
The other thing that helps (which Alex hinted at) is that agents aren't only for real-time alerts, as they can also run on a schedule and send daily/weekly digest-style summaries, analysis and reports eg. "Tell me every what unusual military activity happened over the MENA region this week" which hopefully is more useful. Different muscle for different jobs.
Report
@savannah_l33 That framing is really good — “if it doesn’t change your behaviour, it’s noise” is probably the right test for alerts. I also like the digest angle; sometimes the useful output isn’t an urgent ping, but a pattern summary that helps someone make a better decision later.
Report
about the alert latency. ADS-B data has inherent delays depending on antenna coverage density and how quickly data gets aggregated. for something like a GPS jamming spike where timing actually matters, what's the realistic gap between an event happening and an alert reaching the user. and does coverage quality vary enough by region that some alerts are significantly more reliable than others
Report
Maker
Thanks, that's a really good question @ansari_adin! Aside from station coverage, the data depends on how many flights are in the region at the time, since it's sourced directly from aircraft. We aggregate hourly for that reason, but the dataset can still be noisy (you can see the daily aggregated data on wingbits.com/gps-jamming)
For alerts, we use a rolling 24h window, which should fire fairly quickly if there's a significant spike in well-trafficked areas like the UAE. We're also working on pulling in data from the stations themselves, since they all have GPS and are affected by jamming too.
Report
Maker
@ansari_adin one thing to add, is that coverage quality does vary by region. But we're openly transparent about that. The US and most of Europe have dense enough receiver coverage that alerts fire quickly and reliably.
Our network is growing fast (7x faster than traditional networks), especially in places like Latin America, Asia and Middle East and the alert agents themselves are honest about confidence eg. if the underlying data is thin for a region, the agent will say so. But places like parts of Africa and remote oceanic regions are patchier so less likely to deliver alerts tied to those regions. If you're interested in certain areas, happy to share more specific coverage numbers.
Report
The detail about agents having access to their own alert history and deciding whether enough has changed to flag again is the smart call! If possible to answer at all, where do you draw the line between what the agent suppresses on its own vs what stays a user-tunable threshold?
Report
Maker
@artstavenka1 it depends on the alert. For example, say an agent is set to alert on an emergency alert. The second time it’s detected, the agent has the context of the previous alerts, sees that nothing’s changed in the last 5 min and that you were already informed, so it skips the push. You still see the execution in the dashboard, but the alert isn’t pushed to the destination (Slack, email, etc.).
Report
Wingbits AI
Thanks a lot for a great review @max_morato and thanks a lot for being a part of the community!