Irregular operations are where aviation stops pretending the plan was ever in charge.

Weather moves in. A strike changes available capacity. A technical issue takes an aircraft out of rotation. A diversion creates a new passenger problem at an airport that was never meant to handle it. Crew duty limits tighten. Gates become scarce. Bags go one way, passengers another. Cargo commitments collide with aircraft swaps. The network starts reacting to itself.

This is where real-time data matters most.

Normal operations can hide weak data movement for a surprisingly long time. Schedules are known. Processes are stable. Systems update often enough. People know the usual workarounds. The operation has rhythm.

Irregular operations remove that rhythm.

Suddenly, every delayed update becomes more expensive. Every missing signal creates another phone call. Every disconnected system slows the recovery. Every team optimizes its own part of reality while the network changes around it.

This is why IROPS are the final and probably most important part of this real-time aviation series. They are the stress test. Not of one system, one team, or one dashboard, but of the entire operating model.

IROPS Are Not One Problem

IATA’s interline IROPS guidance defines irregular operations broadly, covering situations such as delays, cancellations, and diversions caused by weather, mechanical issues, crew absence, or other events outside the original operating carrier’s control. That broad definition matters because IROPS are rarely one clean problem. They are usually a chain of operational consequences.

Irregular operations are often discussed as if they were one category, but they are not.

A weather disruption is different from a strike. A strike is different from an aircraft technical issue. A technical issue is different from air traffic flow restrictions. A diversion is different from a mass cancellation. A delay is different from a missed connection wave. A crew shortage is different from a gate shortage. A baggage problem is different from a network recovery problem.

But in real operations, these problems connect quickly.

A weather event may reduce airport capacity. Reduced capacity creates delays. Delays create crew legality issues. Crew legality issues create cancellations. Cancellations create passenger reaccommodation pressure. Reaccommodation pressure affects partner airlines. Aircraft rotations break. Cargo misses connections. Maintenance planning changes. Airport resources become constrained. Customer service load explodes.

That is the beauty and the horror of aviation networks.

Everything is connected, especially when you wish it was not.

Weather Is Not Just Weather

This is why EUROCONTROL’s adverse weather management is such a useful example. Weather disruption is not treated as an isolated forecast problem. It becomes a network coordination problem involving capacity, traffic flow, rerouting, timing, and disruption reduction. That is exactly the kind of environment where late data quickly becomes expensive.

Weather is one of the most common examples of disruption, but operationally it is not just a weather event.

Weather becomes a capacity event. A safety event. A routing event. A fuel planning event. A crew event. A passenger communication event. An airport resource event. A baggage event. A cargo event. A network recovery event.

EUROCONTROL’s adverse weather management work reflects this reality by focusing on anticipation, coordination, mitigation, harmonized weather assessments, proactive planning, and air traffic flow and capacity management measures across ANSPs, airlines, airports, and meteorological service providers. That is the right mental model. Weather disruption is not solved by one team reading a forecast. It is managed through coordinated decisions across the network.

The important data question is not simply “What is the weather?”

The real questions are more operational.

Which airports will lose capacity? Which routes will be affected? Which aircraft may need additional fuel? Which flights are likely to miss connections? Which crews are at risk of timing out? Which passengers need proactive reaccommodation? Which cargo commitments are affected? Which airports may receive diversions? Which recovery options remain realistic?

Weather data becomes useful when it is connected to operational context.

Without that connection, the forecast may be accurate, but the operation still reacts late.

Strikes Turn Data Into Prioritization

Strikes are different from weather because they are usually less about physical conditions and more about capacity, staffing, process availability, and prioritization.

A strike may affect airport employees, ground handlers, security, air traffic control, airline staff, or other operational partners. The consequences can range from slower processing to partial cancellations, reduced airport capacity, baggage handling constraints, longer queues, and major schedule changes.

The hard part is not only knowing that a strike exists.

The hard part is understanding what it means operationally, hour by hour.

Which flights can still operate? Which passenger flows are realistic? Which gates and stands are affected? Which handling resources remain available? Which transfer windows are still credible? Which regulatory or passenger-rights obligations are triggered? Which flights should be protected? Which should be cancelled early enough to avoid worse outcomes?

In these moments, data is not just information. It is prioritization.

If decision-makers do not have current data, they delay hard choices or make them based on incomplete reality. Both are costly.

There is a strange comfort in postponing a difficult decision until more information arrives. In IROPS, that comfort is often expensive. The longer a bad plan remains officially alive, the more passengers, crews, aircraft, bags, and downstream flights become attached to it.

A bad plan that dies early is painful.

A bad plan that dies late becomes a crowd.

Diversions Create New Operational Realities

A diversion is a perfect example of how quickly aviation data needs change.

One moment, a flight is expected at its planned destination. The next moment, passengers, crew, baggage, cargo, aircraft, airport resources, customer service, border control, catering, fuel, maintenance, and onward connections all depend on a new location that may not have been part of the original operational plan.

The aircraft lands somewhere else. Now what?

Can passengers disembark? Are there gates or stands available? Does the crew remain legal? Can the aircraft continue? Does it need fuel? Does it need maintenance inspection? What happens to connecting passengers? Are bags accessible? Is customs or immigration required? Can passengers be accommodated? Is the airport equipped for that aircraft type? Is there a local handler? What does the airline communicate?

This is where stale data becomes especially harmful.

A diversion is not just a flight status update. It is the creation of a new operational reality. That reality must propagate quickly to operations control, crew control, airport stakeholders, ground handlers, passenger service, baggage teams, cargo, maintenance, contact centers, digital channels, and partner airlines.

If it does not, the diversion becomes harder than it already is.

And diversions are rarely looking for help becoming harder.

Delays Are Contagious

A delay is not always a local problem.

A delayed aircraft may affect the next flight. A delayed inbound crew may affect a different aircraft. A delayed passenger wave may affect boarding. A delayed gate release may affect the next arrival. A delayed baggage transfer may affect connection handling. A delayed maintenance decision may affect aircraft assignment. A delayed ATC slot may affect fuel planning and crew duty.

Delay propagation is one of the classic network problems in aviation.

Research on airline disruption management often separates aircraft recovery, crew recovery, and passenger reaccommodation, while also recognizing that integrated recovery is difficult but necessary because the decisions affect each other. Recent work continues to focus on integrated aircraft-crew recovery and passenger reaccommodation within operational decision windows, which reflects the practical reality: recovery decisions are time-sensitive and interdependent.
This is where late data does real damage.

If the delay is known but not shared quickly, downstream teams keep planning against the old schedule. If the downstream impact is calculated too late, the airline loses recovery options. If passengers are notified too late, queues form. If crew legality risk is detected too late, a delay becomes a cancellation. If baggage impact is understood too late, passengers and bags stop sharing the same journey, which is rarely a brand-building exercise.

Aviation delays do not simply happen.

They travel.

The data about them needs to travel faster.

Knock-On Effects Are the Real Enemy

The initial disruption is often not the worst problem, but the knock-on effects are.

A thunderstorm may last two hours. The network impact may last all day. A strike may affect one airport. The passenger and aircraft recovery may affect several hubs. A technical issue may ground one aircraft. The rotation impact may affect multiple flights, crew plans, and maintenance windows.

The operation is not only solving the current problem. It is trying to prevent the current problem from becoming six other problems.

That requires visibility across domains.

Aircraft rotations. Crew legality. Passenger connections. Gate capacity. Ground handling resources. Baggage status. Cargo commitments. Maintenance requirements. Slots. Weather. Airport constraints. Partner airline availability. Hotel capacity. Call center load. Digital communication status.

No single domain owns the knock-on effect.

That is why IROPS need shared operational awareness.

If each team sees only its own slice, each team may make a locally rational decision that creates a globally weaker recovery. Operations may protect aircraft utilization while passengers become harder to recover. Crew control may solve legality while aircraft rotations become inefficient. Passenger teams may offer rebooking options that operational constraints cannot support. Airport teams may manage gates without full visibility of downstream aircraft swaps.

Nobody is wrong in isolation.

The system is wrong together.

Technical View: Real-Time Recovery Needs a Live Operational Nervous System

This is where real-time data architecture becomes very practical.

Irregular operations are not one event. They are a chain reaction. Weather reduces airport capacity. A delay affects an aircraft rotation. The aircraft rotation affects crew legality. Crew legality affects cancellations. Cancellations affect passenger reaccommodation. Passenger reaccommodation affects partner airlines, baggage, gates, hotels, call centers, cargo, and digital communication.

The technical challenge is not simply to store all that data somewhere.

The challenge is to keep the recovery picture alive while the operation is changing.

That is where an event-driven architecture becomes useful. In an IROPS scenario, every relevant operational change should become an event: flight delayed, flight cancelled, aircraft diverted, aircraft swapped, crew legality risk increased, gate conflict detected, baggage connection risk increased, passenger connection risk increased, ATC restriction applied, weather capacity reduced, rebooking inventory changed, recovery plan approved.

Kafka can provide the durable event backbone for those changes. Instead of every system building another fragile point-to-point integration, operational events can be published once, retained, replayed, and consumed by the systems that need them. That matters during disruption because different teams need different slices of the same changing reality. Operations control needs network impact. Crew control needs legality signals. Passenger systems need rebooking and connection context. Airport teams need gate, stand, and passenger flow impact. Cargo teams need aircraft and routing changes. Customer service needs the latest confirmed recovery state.

Flink then adds the real-time processing layer. It can continuously combine events, maintain operational state, detect patterns, and calculate derived signals while the disruption is still unfolding. A missed-connection wave is not one data point. It may depend on inbound delay, outbound boarding status, gate distance, passenger profiles, baggage transfer feasibility, minimum connection rules, and available alternatives. A crew legality risk may depend on duty-time limits, delays, aircraft swaps, positioning, rest requirements, and future rotations. These are stateful, time-sensitive problems.

This is also where AI becomes more credible.

AI should not be the system guessing what the operation looks like. It should reason over live, governed operational context. Kafka helps move and retain the events. Flink helps turn those events into current recovery signals. AI can then summarize impact, explain trade-offs, compare options, support passenger communication, and help humans understand which decisions are still feasible.

In that order.

If AI does not know that the aircraft has diverted, the crew plan expired, the gate is no longer available, or the rebooking inventory changed, it will still generate an answer. That is the dangerous part. During IROPS, a confident answer based on stale data is not helpful. It is operational debt with a nice user interface.

Real-time recovery does not mean automating every decision. It means giving human decision-makers and AI-assisted workflows the freshest possible operational truth before the network loses more options.

AI in IROPS Needs a Live Nervous System

IROPS are an obvious target for AI-assisted decision support.

The potential is real. AI can help summarize disruption impact, identify vulnerable flights, assess passenger connection risk, support reaccommodation, explain recovery options, highlight crew legality issues, estimate downstream effects, and help decision-makers compare scenarios.

But AI in IROPS is also risky if the data foundation is weak.

An AI assistant that does not see current aircraft status may recommend infeasible recovery. An AI assistant that does not know crew legality may protect the wrong flight. An AI assistant that does not see airport constraints may suggest a schedule that collapses at the gate. An AI assistant that does not understand passenger connection risk may optimize the network while creating thousands of angry humans with boarding passes.

That is not artificial intelligence.

That is automated optimism.

In IROPS, AI needs a live nervous system. It needs current operational events, reliable context, permissions, traceability, and decision boundaries. It needs to know what changed, when it changed, what is confirmed, what is estimated, and which constraints are hard.

Otherwise, AI becomes another fast-moving layer on top of slow-moving truth.

That is not modernization. That is latency with a nicer vocabulary.

Customer Communication Depends on Recovery Reality

During IROPS, communication is not only about sending updates.

It is about sending updates that match what the operation can actually deliver.

This is harder than it sounds.

Passengers want immediate answers. Airlines want to communicate proactively. Regulators expect care, assistance, rerouting, refunds, or compensation depending on the circumstances and jurisdiction. IATA’s passenger-rights material highlights care and assistance in delays and rerouting, and refunds or compensation in cancellations where circumstances are within the airline’s control, while also distinguishing disruptions caused by factors such as air traffic control, poor weather, or airport employee strikes.

That means communication must be aligned with both operational reality and policy context.

If a flight may recover, passengers need one message. If it will cancel, they need another. If a connection is no longer realistic, they need proactive guidance. If the airline does not yet know, the system should say so clearly instead of producing confident nonsense. If passenger rights or entitlements apply, the communication must be accurate. If the disruption is outside the airline’s control, that also matters.

Late data makes all of this harder.

A passenger receiving a rebooking option based on stale inventory will not blame the data architecture. A passenger told to wait at a gate after the recovery plan already changed will not appreciate the distinction between operational control and digital communication. A passenger whose app, airport screen, chatbot, and gate agent all disagree will draw one conclusion: nobody knows what is going on.

Sometimes that conclusion is unfair.

Sometimes it is accurate.

Proactive Recovery Requires Early Signals

IROPS recovery improves when teams can act before the disruption fully unfolds.

That sounds obvious, but it requires early signals and trust in those signals.

A weather forecast may indicate reduced capacity. A strike notice may indicate staffing risk. An inbound delay may create crew legality exposure. A technical trend may threaten aircraft availability. A gate constraint may affect the departure wave. A baggage delay may risk misconnected bags. A passenger connection bank may be vulnerable.

The earlier the signal is available, the more options the airline has.

Delay a flight slightly to protect connections. Reassign aircraft. Position standby crew. Prebook hotel capacity. Prioritize cargo. Adjust gates. Reaccommodate high-risk passengers. Communicate earlier. Coordinate with partners. Protect the next departure wave.

Early signals do not guarantee perfect recovery. Aviation is too complex for that.

But they create optionality.

Late signals remove optionality and replace it with apologies.

Real-Time Does Not Mean Instant Everything

IROPS are a strong argument for real-time data, but they are also a strong argument against simplistic thinking.

Not every data element needs instant movement. Not every stakeholder should see everything. Not every decision can be automated. Not every prediction should trigger action. Not every disruption needs the same latency.

The goal is controlled operational relevance.

Which events need to move quickly because they affect recovery decisions? Which stakeholders need them? Which data requires strict access control? Which information is confirmed versus estimated? Which events should trigger workflows? Which should trigger human review? Which should be visible to passenger-facing channels? Which should remain internal?

Good real-time architecture answers these questions deliberately.

Bad real-time architecture just creates noise faster.

Aviation does not need more noise during IROPS. It has enough of that at the service desk.

What Good Could Look Like

A stronger IROPS data foundation would treat operational changes as events that can be shared across the recovery ecosystem.

Weather capacity reduced. ATFM restriction issued. Flight delayed. Flight cancelled. Flight diverted. Aircraft unavailable. Aircraft swapped. Crew legality risk increased. Crew timed out. Gate conflict detected. Baggage connection risk increased. Passenger connection risk increased. Cargo commitment at risk. Hotel capacity constrained. Rebooking inventory changed. Recovery plan approved. Passenger communication sent.

Each event should move to the systems and teams that need it.

Operations control needs network context. Crew control needs aircraft and schedule changes. Passenger reaccommodation needs feasible inventory and connection risk. Airport teams need gate, stand, passenger flow, and turnaround impact. Cargo teams need routing and aircraft capacity impact. Maintenance needs aircraft and rotation context. Customer service needs the latest confirmed recovery state. AI assistants need curated, traceable, authorized context.

This does not require one giant system to own everything.

It requires an architecture that lets the right operational changes move reliably across organizational and system boundaries.

That is the difference between integration as a collection of pipes and data movement as operational infrastructure.

The Real Test of Resilience

Airline resilience is often discussed in terms of fleet flexibility, crew reserves, spare aircraft, robust schedules, and operational playbooks. All of that matters.

But data resilience matters too.

Can the operation still understand itself when the plan breaks? Can it share changes fast enough? Can teams coordinate across domains? Can digital channels stay aligned with operational control? Can AI support decisions without inventing certainty? Can partners see what they need without breaching governance boundaries? Can passengers receive information that is timely, honest, and actionable?

That is the real test.

A resilient operation is not one where nothing goes wrong.

That operation does not exist.

A resilient operation is one that detects change early, shares relevant context quickly, makes coordinated decisions, and prevents one disruption from becoming a network-wide personality disorder.

Not the official term, but anyone who has seen a bad disruption day understands the diagnosis.

Final Thought

Irregular operations are where aviation’s data movement problem becomes impossible to ignore.

Weather, strikes, delays, diversions, crew constraints, aircraft rotations, gate capacity, baggage, cargo, passenger rights, partner coordination, and customer communication all collide. The issue is not only the disruption itself. It is how quickly the network can understand what changed and coordinate a credible response.

That is why real-time data matters.

Not because every decision should be automated. Not because AI will magically solve disruption. Not because one platform, one standard, or one dashboard will remove operational complexity.

Real-time data matters because IROPS are time-sensitive, multi-party, high-cost coordination problems.

When data is late, the airline loses options. When context is fragmented, teams optimize locally. When passenger communication is disconnected from recovery reality, trust breaks. When AI sees stale information, it becomes confidently unhelpful at scale.

The goal is not perfection.

The goal is earlier awareness, better coordination, and fewer avoidable surprises.

Because in irregular operations, late data is not just late.

It is a cancellation that could have been communicated earlier. A crew plan that quietly expired. A diversion that became harder than necessary. A missed connection wave nobody saw in the same system at the same time. A recovery plan that looked sensible until reality sent its own update.

And reality, as usual, did not wait for the batch job.

Articles in this series

The articles below are part of this series. New posts will appear here automatically once they are published.