Cathay transformed its monitoring landscape with Elastic Cloud, bringing previously disconnected data together on a single platform. The result was a 30% reduction in operational IT noise and greater visibility and alignment for infrastructure and security teams across 300+ applications.
Summary
For 80 years, Cathay has connected people, places, and experiences through its travel lifestyle ecosystem, with Cathay Pacific serving as its premium airline. Today, the group operates more than 300 mission-critical applications across over 100 stations worldwide. As its digital operations grew, infrastructure and security teams relied on multiple monitoring tools and disconnected data sources, making it difficult to gain a clear view of the passenger experience. Rather than focusing solely on system metrics such as CPU and memory, the airline wanted to understand how critical customer journeys — from flight booking to payment — were performing end to end. By moving from a self-managed on-premises deployment to Elastic Cloud and consolidating telemetry into a single platform, Cathay gained a unified view of both technology performance and business transactions. The result was a 30% reduction in operational noise, faster issue resolution, and stronger collaboration between teams that now work from the same set of data. Here's how they did it.
A global airline that runs on connection
What does it take to keep an 80-year-old airline flying? Connection. Constant, invisible connection.
Cathay Pacific Group flies out of Hong Kong and runs more than 300 mission-critical applications across 100+ stations worldwide. None of them stands alone. Every time a passenger books a flight, checks a bag, or boards a plane, dozens of systems have to talk in the background. Rajeev Nair, who oversees the organization's infrastructure and cybersecurity, leads this work. With a career in keeping airlines in the air spanning 25 years, he still keeps his phone on all night in case something breaks.
The thing he sees every day is how connected it all is, and how the old monitoring model hid that.
After moving to Elastic Observability on Elastic Cloud, the team cut about 30% of its operational IT noise and, more importantly, could finally watch a booking as a single business transaction, rather than a scatter of infrastructure metrics.
"Every booking is the end of a long chain: fare rules, inventory, booking codes, passenger profiles, payment providers. If the website looks slow to a passenger, the website is almost never the problem. The trouble is somewhere else in that chain, and in the old model we could not see the whole chain in one place."
In 2014, Cathay Pacific began a major modernization journey aimed at building a more resilient, scalable, and customer-focused technology foundation. Over the following decade, the airline moved 98% of applications off legacy infrastructure, rebuilt them for the cloud, modernized a global network of 100+ stations, and unified observability and security on a single platform.
From green terminals to the cloud
The starting point was hard. Cathay's reservation and ticketing systems ran on mainframes — the green-terminal era — hosted in a data center in Australia. More than 300 business applications lived on-premises in the group's own data centers, and for an airline this old, a lot of that estate was genuinely legacy.
Recognizing that its legacy technology environment could not support its long-term ambitions, Cathay Pacific launched a multiyear transformation to modernize its infrastructure, applications, and operating model.
The journey unfolded in phases. The airline first migrated its mainframe reservation and ticketing systems, then progressively moved applications to the cloud; starting with lift-and-shift migrations, before redesigning them for a cloud-native future. As the volume of telemetry grew, data evolved from an operational necessity into a source of business insight — helping teams understand not just system health, but also the customer experience behind every transaction.
Finally, it revamped the global network connecting 100+ stations back to Hong Kong to be more scalable and cost-efficient. Across that decade, roughly 98% of applications moved off legacy infrastructure.
Monitoring came along for the ride, and the limits showed. Early on, different teams ran their own scripts, and nothing was searchable across them. Moving to a self-managed Elastic Stack on-premises helped, but it could not keep pace with the containerized, cloud-first workloads coming online, and it kept the team anchored to on-premises infrastructure that the rest of the estate was leaving behind.
Before: Monitoring the servers, missing the passenger
Before everything came together on Elastic Cloud, the daily pattern was familiar to anyone who's run split teams.
Different teams looked at different tools. Platform engineers watched one set of data points, while security analysts watched another — and the formats did not match. When an incident hit, the first stretch of every response went to a single unproductive question: Is this an infrastructure problem or a security problem?.
Both teams were staring at different pieces of the same event.
Three burdens kept showing up. First, the self-managed, on-premises deployment meant constant patch upgrades, server lifecycle work, software updates, and hardware maintenance, a tax on people whose real job was observability. Second, static logging did not fit a containerized world: the workloads and platform were dynamic, but the old logging approach was not. Third, monitoring watched infrastructure symptoms rather than business outcomes, so the team could see a CPU spike but could not easily trace it back to the booking it was breaking.
Their time went into triaging scattered alerts, reconciling data formats across tools, and debating who owned the problem, rather than into the work that mattered.
1 Elasticsearch data layer for every team
The unification is based on Elasticsearch as a single data and search layer.
Observability telemetry from cloud-native applications, and the security-relevant telemetry the security team cares about, flow into one Elastic Cloud deployment with one schema and one query language for everyone.
That single structural choice is what lets the infrastructure team and the security team look at the same data and ask different questions. So, the datastore is no longer the background plumbing, but rather the thing that makes the new way of working possible.
As logs arrive from many systems, structured and unstructured, in different native formats, they are streamlined into one consistent format on the way in, so teams stop wrestling data into shape to fit a tool and start reading it.
The security team brings its security-relevant telemetry into the same layer and works from it for threat-hunting, vulnerability management, and incident and risk management, while the platform team works from it for availability and resilience. On top of that shared layer, Cathay Pacific now monitors business functions, booking, payment, and inventory, as end-to-end transactions, with the upstream and downstream data points stitched together so a problem surfaces before it cascades.
Technical highlights
- Single Elastic Cloud deployment ingesting observability and security-relevant telemetry across 300+ business-critical applications
- Coverage spanning 100+ stations worldwide
- Container-native observability in place of legacy static logging
- One consistent schema across structured and unstructured data sources
- Business-transaction monitoring for booking, payment, and inventory as named functions, not just infrastructure metrics
- Security team working from the same data layer for threat hunting, vulnerability management, and incident and risk management
- Managed Elastic Cloud in place of a self-managed, on-premises deployment, removing patch, upgrade, and hardware maintenance work
What the change unlocked
Numbers tell you something shifted. The more interesting story is what that shift freed people to do.
2 teams, 1 source of truth
The first capability isn't a tool at all, but rather, a new working agreement.
When platform engineers and security analysts look at the same data in the same place, the first 30 minutes of every major incident change shape. The ownership debate disappears, leaving security to focus on threat hunting and the platform team on availability and resilience. But now, both ground their judgment in the same evidence.
"When an incident happens, there is no longer a debate about whether it is a security incident or a platform issue. Both teams are looking at the same data points and the same triggers. Security can focus on threat hunting, and the platform team can focus on availability."
Watching the business, not just the box
Booking is the example Rajeev often uses to explain the change.
During a peak-season sale, a passenger encountering a slow payment page has no visibility into the complex systems working behind-the-scenes. They only know that the booking experience is failing.
Historically, teams monitored individual infrastructure components, chasing spikes in CPU or memory usage after a problem had already surfaced. Today, Cathay monitors the entire booking journey as a single business transaction. With end-to-end visibility, teams can quickly pinpoint where issues begin and understand how they may affect downstream services.
The result is a shift from reactive troubleshooting to proactive problem-solving. Engineers can focus on resolving the root cause before it affects customers, helping deliver a more reliable booking experience while reducing operational effort.
That's the real shift the team talks about: from watching servers to watching business outcomes.
Time given back
When the team moved off the self-managed deployment, the most measurable win was the disappearance of patch management, server upgrades, end-of-life software, and hardware maintenance.
That work didn’t vanish, but it did stop becoming a problem that Cathay Pacific has to prioritize. The team puts the drop in operational IT noise at about 30%, and the recovered time went straight back into observability and root-cause work, where it actually creates value.
"By moving to Elastic Cloud we cut about 30% of the operational noise — the patching and hardware work that was never our real job. I would rather be told something is going wrong early than find out after the whole estate is affected, and now the team can act earlier and stay proactive."
From signal to action
Here's the operating model in practice.
A security analyst starts the morning looking at the same data the platform team sees. When a trigger fires, the context is already assembled, with data points from upstream and downstream systems stitched together.
The analyst's job is now to read the picture, judge it, and decide whether to escalate — not to spend an hour pulling that picture together from five different tools. When it's a real security event, the response moves faster, because nobody reconstructs context. When it isn't, the platform team picks it up from the same dashboard.
Before and after
| Before | After | |
|---|---|---|
| Alert management | Fragmented across siloed tools; teams debated ownership | Unified on one platform; teams start from the same data |
| Operational effort | Patch upgrades, server maintenance, and hardware lifecycle on a self-managed deployment | ~30% less operational IT noise; effort redirected to observability work |
| Investigation flow | Different teams, different tools, different data formats; time lost reconciling before investigating | One data layer, one query language; the ownership debate is gone |
| Monitoring focus | CPU, memory, and infrastructure symptoms | Business transactions: booking, payment, and inventory as named functions |
| Incident detection | 5–6 major incidents a day; MTTR 4+ hours; firefighting mode | Early detection of cascading issues; teams shifting to prevention |
| Analyst and engineer role | Triage, tool reconciliation, and manual context assembly | Root-cause analysis, judgment, and proactive prevention |
What comes next?
Cathay is watching a few shifts closely.
Passengers expect personalized experiences, and that depends on a technology stack that can deliver them in real time. AI is moving from experiment to enterprise scale, and the team is deliberate about staying model-agnostic to avoid lock-in as the landscape shifts. In addition, Nair wants to collapse the boundary between observability and workflow management with one platform for both the signal and the action, rather than separate stacks.
And in aviation, predictive capabilities are spreading beyond engineering maintenance into customer-facing functions like dynamic fare rules.
"I no longer want one tool stack for observability and a separate tool stack for automation and self-service. I would rather have one platform layer for end-to-end fulfillment, whether that's observability or customer support. The next step is moving from 'here is the signal' to 'here is the recommended action,' and eventually, automating those recommended steps so the team can focus on the work that actually requires judgment."
As Cathay's premium airline, Cathay Pacific has spent 80 years connecting people, places, and experiences through a network that now spans more than 100 stations worldwide. Your organization may not run 300 applications across 100 stations, but the same principle holds — whether you're starting with a single business-critical workflow or scaling to Cathay’s footprint: unify the data, let the platform handle the context, and free your team to do the work that takes real judgment.
See how Elastic Observability brings telemetry from across your stack into one place to monitor the business, not just the boxes, or start now with a free trial.