Where the data comes from
SkyMeter is a derived-data platform. We do not generate or simulate the flight path you see. Each replay is reconstructed from public and third-party aviation data sources, then enriched with runway, airport, aircraft, and weather context. The main data categories are:
- Public flight traces: aircraft position, altitude, groundspeed, vertical rate, track, squawk, and related broadcast-derived fields from community receiver networks and historical archives.
- Surface weather: METAR and related observations from public aviation weather sources.
- Upper-air and forecast weather: atmospheric datasets used to estimate wind, temperature, pressure, and other conditions along the flight path.
- Runway and airport reference data: airport location, runway geometry, runway elevation, pavement information, and related airport metadata from public aviation datasets.
- Aircraft reference data: aircraft type, category, performance references, and type-designator information from public and industry-standard sources.
SkyMeter combines those inputs into an enriched flight record that powers the 3D replay, cockpit-style instruments, airport dashboards, incident pages, exports, search, and API access. Where required, SkyMeter provides attribution for source datasets; some source flight data is licensed under the Open Database License, and qualifying processed replay data is made available under compatible terms.
Important context
SkyMeter is not a flight data recorder. Public flight traces are powerful, but they are not the same as certified onboard data. They can contain gaps, delayed samples, altitude quirks, receiver dropouts, duplicate points, incomplete coverage, aircraft-equipment differences, and weather uncertainty.
SkyMeter's detectors are designed to surface useful aviation signals from public data. They are not accident findings, regulatory conclusions, pilot grades, or claims of fault. A detected event means: the available public data matched a defined SkyMeter event model. It does not mean SkyMeter knows everything the crew, ATC, airline, aircraft systems, or investigators knew.
How are go-arounds detected?
SkyMeter detects likely go-arounds by looking for an aircraft that descends onto a runway-aligned final approach, reaches a low altitude above the runway environment, and then climbs away instead of continuing to land. The model looks at several signals together:
- runway alignment
- descent onto final approach
- low-altitude state near the runway
- subsequent climb-away behavior
- groundspeed and vertical-rate behavior
- continuity of the flight trace
- aircraft type and operating context
SkyMeter distinguishes likely go-arounds from several lookalike cases, including pattern work, touch-and-go training, missed or incomplete traces, and aircraft that were never actually established on final. General aviation training can create many false positives because repeated pattern work often includes low approaches, touch-and-goes, and intentional climb-outs, so some event types are treated differently by aircraft category and operating pattern.
A go-around detection should be read as: the aircraft appeared to discontinue a runway-aligned approach and climb away based on the available public data. It should not be read as proof of a safety incident or pilot error.
How are unstable approaches detected?
SkyMeter's unstable-approach detector is based on established stabilized-approach concepts used in aviation safety programs. A stabilized approach generally means the aircraft is properly aligned, on an appropriate vertical path, at a controlled descent rate, within a reasonable speed band, and not making excessive corrections close to the runway. SkyMeter evaluates these dimensions around the stabilization portion of the approach:
- runway centerline alignment
- track alignment with the runway
- glidepath or vertical-path behavior
- descent rate
- speed behavior
- bank, turn, or lateral correction behavior
The model is grounded in the Flight Safety Foundation Approach-and-Landing Accident Reduction (ALAR) framework and common FAA, ICAO, airline, and training concepts around stabilized approaches. SkyMeter does not claim that every operator uses the same thresholds. Airlines, aircraft types, training organizations, and safety departments may define their own gates and tolerances. SkyMeter applies a consistent public-data model so approaches can be reviewed and compared across airports, runways, aircraft types, and time periods.
SkyMeter keeps the approach score and the unstable-approach flag separate. The approach score is a graded 0–100 quality measure across the approach; the unstable-approach flag is a binary event detection that asks whether the aircraft appeared outside stabilized-approach criteria near the stabilization gate. Usually the two agree; when they don't, the score breakdown is usually more informative because it shows which dimension caused the deduction and at what altitude gate. For exactly how the score is built, see How we score approaches & landings.
Per-runway approach context
Not every runway is flown the same way. Some approaches are straight-in and conventional; others involve offset final segments, curved RNAV paths, terrain-driven procedures, displaced thresholds, visual turns, water approaches, or unusual local traffic patterns.
SkyMeter compares approaches not only against general stabilized-approach concepts, but also against runway-specific behavior where enough historical data exists. That allows the system to identify whether an approach was unusual for that specific runway, rather than forcing every airport into one universal shape. That helps reduce false positives at airports where the normal approach path is already offset, curved, steep, or operationally unusual.
How are stall-like events detected?
SkyMeter detects possible stall-like events by looking for a sustained low-speed state, altitude loss, and flight-path behavior consistent with a loss of lift or stall-recovery profile. Because public flight data does not broadcast angle of attack, flap position, aircraft weight, or exact cockpit configuration, stall detection is inherently limited. The model uses available signals such as:
- estimated airspeed behavior
- aircraft type and category
- altitude trend
- descent behavior
- turn behavior
- recovery behavior
- known training-aircraft context
A large share of stall-like detections on trainer aircraft may represent intentional training maneuvers, not safety incidents. Common piston trainers are often used for stall recognition and recovery practice. For that reason, SkyMeter treats stall-like events carefully and provides context when the aircraft type or flight profile suggests training activity. A stall-like detection should be read as: the public data resembled a stall or stall-recovery profile. It should not be read as proof that an unsafe stall occurred.
How are runway events detected?
SkyMeter detects runway-related events by comparing the aircraft's ground path and rollout behavior against runway geometry. These models look at the likely runway used, a touchdown-zone estimate, runway centerline position, lateral deviation from the runway, longitudinal position along the runway, groundspeed during rollout, deceleration behavior, and whether the aircraft remained within the expected runway environment. Runway-related event types may include long landings, unusual rollout behavior, possible overrun indicators, or possible lateral runway excursion indicators.
These detections are among the most sensitive to runway matching accuracy. Parallel runways, closely spaced taxiways, poor ground coverage, airport shadow zones, and incorrect runway attribution can all create false positives. For that reason, SkyMeter suppresses or limits public surfacing of runway-event classes that are still under audit for specific airports or runway configurations.
How are pitch, roll, and heading reconstructed?
Public flight data usually includes position, altitude, groundspeed, track, and vertical rate. It does not directly broadcast aircraft attitude. SkyMeter reconstructs attitude cues from the movement of the aircraft through space:
- Pitch: estimated from climb or descent behavior relative to speed.
- Roll / bank behavior: estimated from turn rate, track change, and speed.
- Heading: estimated from ground track and wind correction where weather data supports it.
These values are designed to make the 3D replay and cockpit-style instruments more useful. They are not certified attitude data and should not be treated as equivalent to an aircraft's onboard AHRS, IRS, or flight data recorder. Where the underlying flight trace has gaps or uncertainty, the replay may smooth or interpolate movement for visual continuity, and SkyMeter marks or limits analysis where data quality is not good enough for reliable detection.
How is airspeed estimated?
Many public flight traces provide groundspeed, not indicated airspeed. Groundspeed is how fast the aircraft moves over the ground; indicated airspeed is what matters more directly for aircraft handling and approach stability. SkyMeter estimates wind-aware speed behavior by combining aircraft groundspeed, ground track, altitude, weather-derived wind estimates, atmospheric conditions, and aircraft type context where available. This allows SkyMeter to interpret cases where groundspeed alone would be misleading, such as strong headwinds, tailwinds, or crosswinds.
However, estimated airspeed is still an estimate. Public data does not include exact aircraft weight, flap setting, gear position, power setting, or cockpit-indicated values. For that reason, SkyMeter treats airspeed-derived metrics as analytical estimates, not certified cockpit readings.
Where aircraft broadcast their own airspeed, SkyMeter uses it to check its work. A subset of modern airliners transmit indicated airspeed and Mach directly, giving an independent, real-world reference. SkyMeter routinely compares its wind-aware estimates against these broadcasts across a range of aircraft types and altitudes, and the estimates track the broadcast values closely, typically within a few knots. Flights that don't broadcast their airspeed are handled by the same approach, validated on the ones that do.
Broadcast airspeed is not always clean. Transponders occasionally transmit corrupt or physically impossible values: brief decode errors that would otherwise distort a reading or trigger a false alert. SkyMeter checks broadcast airspeed for plausibility and discards values that cannot be real, so a single bad transmission doesn't contaminate the analysis. When a value can't be trusted, SkyMeter prefers to withhold it rather than publish something wrong.
Known limitations
SkyMeter intentionally excludes or suppresses detections when the data is not strong enough. Common limitations include:
- Coverage gaps: oceanic, remote, or low-altitude areas may have sparse receiver coverage.
- Signal loss near airports: some airport environments have poor low-altitude or ground coverage.
- Receiver shadowing: buildings, terrain, airport layout, or receiver placement can distort coverage.
- Altitude artifacts: pressure-altitude behavior can differ from true height above the runway, especially near sea level or unusual pressure conditions.
- Weather uncertainty: weather observations may be distant from the aircraft, time-shifted, or different by altitude.
- Runway ambiguity: parallel runways and closely spaced airport geometry can make runway matching difficult.
- Training flights: pattern work, stall practice, low approaches, and touch-and-goes can resemble safety events when viewed only through public data.
- Missing configuration: public flight traces generally do not include flap position, gear position, aircraft weight, power setting, or cockpit-selected modes.
When the data is too sparse or ambiguous, the better answer is no event, not a confident-looking detection built on weak evidence. SkyMeter may exclude an approach or event from public scoring when the final approach trace has major gaps, the runway match is uncertain, the aircraft disappears before the key event window, the apparent event depends on a single bad sample, the aircraft type or context makes the detector unreliable, the airport is known to have local data-quality issues for that event type, or the event class is still being audited. This is especially important for public incident pages: SkyMeter would rather miss some marginal events than publish large numbers of obvious false positives.
How fresh is the data?
SkyMeter is not designed as a live radar display. Flights usually appear after landing once the relevant public data has been processed, enriched, and indexed. SkyMeter focuses on what is difficult to see live: replay, analysis, historical search, airport trends, event discovery, exports, and API access. Airport, aircraft, airline, and incident pages show the data window being analyzed so users can tell what period the page represents.
Questions about a specific detection?
Every SkyMeter replay has a short code in the URL. If a detection looks wrong,
questionable, or interesting, email
[email protected] with the replay
code (e.g. C0OhdE7R from a URL like /replay/C0OhdE7R)
and the event name. We can review the specific flight, explain what the
detector saw, and correct bad detections where appropriate.
For broader platform details, see the broader methodology, the approach-score methodology, the About page, and the FAQ.