Flight Data Monitoring: The Complete Guide

What Is Flight Data Monitoring?

FDM, FOQA, and Flight Data Analysis (FDA) are largely interchangeable terms for the same underlying activity: regularly recovering data from an aircraft’s flight data recorder or quick access recorder, processing it through specialized software, and analyzing the results to spot safety and efficiency issues. “FOQA” is the term most commonly used in North America; “FDM” is more common in Europe and under ICAO terminology; “FDA” shows up in some regulatory documents. You’ll see all three used by operators, regulators, and vendors, often within the same document.

The core idea predates the software that now makes it practical. Flight data recorders have existed for decades, but for most of that time they were used almost exclusively as accident investigation tools — a black box you hoped you’d never need to open. FDM flips that around: by analyzing data from routine, non-eventful flights as a matter of course, operators can find the precursors to an accident long before one happens. A go-around that’s slightly later than it should be, an approach that’s consistently a bit fast, a landing that’s longer than normal. None of these are accidents on their own, but patterns in them tell you where your real operational risk is.

For a deeper walkthrough of the basics, see our introduction to Flight Data Monitoring and FOQA, and for a plain-language explanation of what an “event” actually is in this context, see What is a Flight Data Monitoring or FOQA Event?

Why Flight Data Monitoring Matters

Regulatory drivers

FDM isn’t just a best practice — for a large segment of commercial aviation, it’s a requirement. ICAO Annex 6 has required operators of aeroplanes over 27,000 kg MTOW to establish and maintain a flight data analysis programme as part of their safety management system since 2008, and similarly recommends it for larger helicopters. Individual regulators implement this in their own ways: EASA’s framework continues to evolve, most recently with new requirements affecting runway excursions, unstable approaches, and take-off performance gaps taking effect January 1, 2028 — we cover what’s changing and who’s affected in EASA’s 2028 FDM Requirements. In the U.S., the FAA’s FOQA program (Advisory Circular 120-82) is voluntary but includes specific protections in 14 CFR Part 13 that limit how the agency can use voluntarily submitted data in enforcement actions — a deliberate design choice meant to encourage operators to participate without fear of being punished for what their own data reveals. IATA’s IOSA standards also reference FDM/FOQA participation as part of operational safety audits.

If you’re trying to understand what your specific program actually needs to include — not just whether you’re required to have one — see Understanding Flight Data Monitoring (FDM) Program Requirements.

The safety case

The regulatory requirement exists because the safety case is strong. FDM consistently surfaces risks that no other part of a safety management system reliably catches, because it’s built on objective, recorded data rather than self-reported observations. Our 2026 Global Data Sharing Report, which analyzed roughly 104,000 landings across our customer base, found a measurable long-landing trend that most operators’ existing FDM thresholds weren’t catching — see The Long Landing Blind Spot for what we found and why standard event definitions can miss this kind of risk entirely. We’ve seen similar blind spots in other event categories: false-positive-heavy glideslope and localizer events that bury real signal in noise (see How We Cut False Glideslope and Localizer Events by 85%), and traffic conflict events that traditional FDM parameter traces don’t fully explain on their own (see Your FDM Program is Missing Half the Picture, on using ADS-B data alongside FDM data for TCAS events).

The business case beyond safety

Safety is the foundation, but it’s not the only return. The same flight data that flags an unstable approach can also flag a high-fuel-burn flight, an engine trend that’s drifting toward a maintenance issue, or an operational procedure that’s quietly costing money across the fleet. We go through this in more detail in Beyond Safety: The Real ROI of Flight Data Monitoring and, on the maintenance side specifically, in Use Your Flight Data to Monitor Engine Health. For operators who are still building the internal case to leadership for investing in a program at all, the most persuasive argument is often the cost of not having one — see Flight Data Monitoring Works – If You Use It for a real example of how a single avoided runway overrun event can pay for years of program cost.

​How an FDM Program Actually Works

Strip away the regulatory language and an FDM program is a fairly simple loop, repeated every flight, every day:

1. Download. Data is recovered from the aircraft’s flight data recorder (FDR) or, more commonly for FDM purposes, a quick access recorder (QAR) — a separate, more easily accessible recorder designed specifically for routine data extraction rather than crash survivability. Depending on the aircraft and installation, this can happen via physical media, a download unit, or increasingly, automated wireless transfer. For a closer look at the hardware side, see Flight Data Monitoring and FOQA: Flight Data Recorders.

2. Process. Raw recorder data isn’t directly human-readable — it has to be decoded against the aircraft’s specific parameter map (often called a FRED file, short for Flight Data Recorder Event Definition) and run through FDM software that converts it into usable parameters and flags pre-defined events. We go into what a FRED file actually is and why it matters in What is a FRED File and why is it so Important?

3. Analyze. This is where the real work happens. An analyst (or a team of analysts, depending on program size) reviews flagged events, separates genuine safety signal from noise, and looks for trends across many flights rather than reacting to single events in isolation. Raw flight data is never perfectly clean — recorders drop parameters, sensors drift, and some data has to be interpolated rather than measured directly — so understanding the limitations of your data is part of doing this well. We’ve written about this at length in Bad Flight Data – Part 1 and Part 2, Understanding the Accuracy of Flight Data, and Working With Interpolated Flight Data. Good chart and visualization practices matter here too — see 5 Tips for Flight Data Monitoring/FOQA Charts and Graphs.

4. Act. None of the above matters if it doesn’t change anything. The findings need to feed back into training, procedures, or maintenance decisions — and ideally into your broader Safety Management System rather than sitting in a standalone FDM report (more on that below).

Software vs. Managed Service: Choosing Your Model

Operators generally choose between running FDM software themselves in-house, or using a managed service where a third party (like us) handles the analysis on their behalf. Neither is universally “better” — it depends on your fleet size, internal resources, and how much you want flight data expertise to live inside your own organization versus outsourced. We walk through the tradeoffs in Flight Data Monitoring Service vs. Software: Which is Best for You? One thing worth knowing going in: a higher price tag doesn’t automatically mean a better program. We’ve seen plenty of operators get sold an expensive legacy solution that delivers less practical value than a more modern, better-supported platform — see FDM and FOQA Software: More Expensive does not Mean Better.

Common FDM Event Types & What They Reveal

A handful of event categories make up the bulk of what most FDM programs spend their time on. Understanding what each one actually signals — rather than just whether a threshold was crossed — is most of the analytical skill in this field.

• Unstable approaches and go-arounds. Despite the name, a go-around isn’t a failure — it’s often the system working correctly. We unpack why this event is frequently misunderstood in Flight Data Monitoring and FOQA: Why don’t We Just Go Around?
• Long landings and runway excursions. Among the highest-consequence event categories in aviation safety, and one where standard thresholds can miss real risk — see The Long Landing Blind Spot and Runway Overruns and Flight Data Monitoring: Another Approach?
• Incorrect altimeter settings. A deceptively simple error that’s contributed to a number of high-profile incidents — see Flight Data Monitoring: Incorrect Altimeter Settings
• Glideslope and localizer deviations. Frequently one of the noisiest event categories in any FDM program — see How We Cut False Glideslope and Localizer Events by 85%
• Traffic alerts and TCAS events. Parameter traces alone often don’t tell the full story of what a crew actually experienced — see Your FDM Program is Missing Half the Picture
• Geofence and spatial events. A newer category enabled by modern FDM platforms, useful for monitoring activity in specific airspace or airport zones — see Geofencing in FDM: Turning Flight Data into Spatial Insight

Privacy, Data Ownership & the Non-Punitive Principle

The single biggest internal barrier to a successful FDM program isn’t technical — it’s trust. Pilots understandably want to know that flight data won’t be used against them personally, and getting this wrong undermines the entire purpose of the program: people fly differently, and report less honestly, when they believe they’re being watched for punishment rather than monitored for improvement. ICAO’s own framework requires that flight data analysis programmes be non-punitive and include adequate safeguards to protect the source of the data, and most mature programs go further with formal de-identification processes that separate flight data from crew identity before it’s reviewed.

We cover how this typically works in practice in How We Protect Pilot Privacy While Empowering Flight Data Insights and Flight Data Monitoring and FOQA: Data De-Identification. The question of who actually owns the flight data in the first place — the operator, the OEM, the crew — is less settled than most people assume, and worth understanding before you’re in a dispute about it; see Safety First? Whose Data is it Anyway?

Integrating FDM with Your Safety Management System

FDM shouldn’t operate as an island. The events, trends, and findings it produces are most valuable when they feed directly into your broader Safety Management System (SMS) rather than living in a separate report that safety managers have to manually cross-reference against voluntary reports and other safety data. Closing that gap — so that FDM data and SMS reporting reinforce each other instead of operating in parallel — is one of the more impactful things an operator can do to mature their safety program. We go into this in Closing the Gap Between FDM and SMS: Why Integrated Reporting Matters More Than Ever and Integrating SMS and FDM: Elevating Aviation Safety to New Heights

Common Myths About FDM

A lot of operators delay starting an FDM program based on assumptions that don’t hold up — that it’s punitive, that it’s only for airlines with large fleets, that it requires a dedicated data science team, or that it’s prohibitively expensive to set up properly. We address the most common of these directly in Top 5 FOQA/Flight Data Monitoring Myths, and on the “what counts as official approval” question specifically, in Understanding FDM Approval: A Common Misconception — FDM software itself isn’t “approved” or “certified”; it’s the entire program, as implemented by the operator, that goes through regulatory approval.

Getting Started: Launching Your First FDM Program

If you’re new to FDM, the good news is that you don’t need prior data analysis experience or a large team to get a program running and producing real safety value. The basic steps look like this:

1. Define your objectives before you pick a tool. What are you actually trying to find out — unstable approaches, fuel efficiency, engine trends, all of the above? Vague objectives lead to programs that generate a lot of data and very little decision-making.
2. Decide on software vs. managed service based on your fleet size and internal resourcing (see the section above).
3. Get your data recovery method sorted first. Whether that’s a QAR with a download unit or a wireless transfer setup, this is the part that has to work reliably before anything downstream matters.
4. Build the non-punitive policy and de-identification process before you launch, not after. This is the trust foundation the whole program depends on, and it’s much harder to retrofit credibly once pilots have reason to be skeptical.
5. Start with a manageable set of event definitions and expand as your analysts (or your service provider’s analysts) build familiarity with your specific operation. A smaller, well-understood event set beats an overwhelming one that nobody has time to triage properly.
6. Close the loop. Decide upfront how findings will actually reach training, procedures, and your SMS — not just how they’ll be detected.

This is also where the choice between a self-managed program and a guided one matters most for first-time operators. If you’d rather have an experienced team handle the setup and ongoing analysis while you focus on acting on the findings, that’s the exact gap Sky Analyst FDM is built to fill.

Frequently Asked Questions

Is FDM the same thing as FOQA? For practical purposes, yes. FDM is the term more commonly used in Europe and in ICAO terminology; FOQA is the term most commonly used in North America. Both refer to the same underlying activity of routinely analyzing recorded flight data for safety and efficiency purposes.

Is Flight Data Monitoring mandatory? It depends on your aircraft and operation. Under ICAO Annex 6, operators of aeroplanes over 27,000 kg MTOW are required to maintain a flight data analysis programme; specific national and regional regulators (such as EASA) layer additional requirements on top of this, and these requirements continue to evolve. In the U.S., the FAA’s FOQA program is voluntary, though strongly encouraged and increasingly expected by customers, insurers, and industry standards like IOSA. Smaller operators below regulatory thresholds aren’t required to run a program but increasingly choose to for the safety and efficiency benefits.

Will FDM data be used to discipline pilots? A properly run FDM program is explicitly non-punitive by design, and this is a regulatory requirement in most frameworks, not just a best practice. Most programs use de-identification to separate flight data from crew identity before analysts review it, specifically so the program can’t be used as a disciplinary tool.

How much does an FDM program cost to set up? This varies significantly based on fleet size, aircraft data infrastructure, and whether you choose a software or managed-service model. Modern cloud-based platforms have meaningfully lowered the cost of entry compared to legacy systems, which is part of why FDM has become accessible to smaller operators who previously assumed it was an airline-only tool.

What aircraft data do I need to run FDM? At minimum, you need access to recorded flight data — typically from a quick access recorder (QAR) — and a way to regularly extract it. Some older aircraft may need a QAR retrofit if one isn’t already installed.

Flight Data Monitoring isn’t a box to check for compliance — it’s one of the most effective tools available for finding the risks in your operation that nothing else will surface. If you’re just getting started, browse the articles linked throughout this guide for the specific topics most relevant to where you are, or get in touch if you’d like to talk through what a program would look like for your operation.