Observability for airline and aviation IT systems

Wrentrix is designed with airlines in mind, among other regulated organisations. That is a design goal and not a customer list. No airline is described on this page, and all the scenarios are invented.

Scope first: what this is not for

This page is about commercial and ground IT: booking, check-in, departure control interfaces, crew and operations portals, loyalty, and the APIs that link them. Wrentrix is not an avionics product, isn't a flight safety system, and we make no claim of aviation certification. Keep safety-critical systems under their own assurance regimes.

How traffic behaves in an airline

Few industries have such an unusual load shape. Knowing it helps you design alerts that make sense.

The last row is what makes this domain unusual. Normally, unusual traffic is a warning. During a disruption, it is exactly what you'd expect, and your job is to know whether your systems are coping. Hour-of-week baselines will flag everything as anomalous, correctly, and they won't tell you much. What you need at that point is SLO burn rate on the journeys that matter: can a passenger rebook? Can an agent print a boarding pass? Those questions don't depend on what's normal.

The same logic applies to seasonal schedule changes. A summer schedule can add frequencies that move the weekly shape, so baselines need a few weeks to catch up. Plan for a noisier spell after a schedule change, and don't lower alert sensitivity permanently because of it.

An example: check-in slows at one hub

An invented scenario. At 06:40, agents at one hub report that boarding pass printing is slow. Other stations are fine. On a global dashboard, nothing is visibly wrong, as this hub's traffic is a small slice of the whole.

• RUM for the browser-based agent application, filtered to the affected route, shows slow fetches for that population. Real user monitoring gives you p75 and the good, needs-work and poor split, and the session timeline shows the sequence an agent saw.
• Each fetch links to its backend trace through traceparent. The trace shows time accumulating in the call to the document service, while the airport network path looks fine.
• Method data and pod details show only some pods running slowly. Those are on a recent rollout.
• Change correlation shows that a rollout started at 05:50 and is halfway across, and that the morning peak is the first real load on the new version. The stations going through those pods are slow.
• Rolling back stops the slowdown before the next departure bank.

Without the join from browser to backend, this typically turns into a discussion about whether the airport network is to blame.

Where the links to others break

An airline's IT depends heavily on external parties: reservation and distribution platforms, payment providers, airport systems, border data services, partner carriers, and more. You don't control these, you can't instrument them, and when they slow down, your customers hold you responsible.

What you can do is measure your side of each boundary:

1. Name each dependency clearly in traces. Client spans to outside services should identify the peer in a consistent way, so your dependency map shows them as distinct nodes, and not as one undifferentiated "external" box. The current semantic conventions use attributes like server.address.
2. Split your latency. "Our service took 3 s, of which the partner took 2.8 s" is an excellent fact to take to a supplier meeting, and it saves your engineers from looking in the wrong place.
3. Probe the partner paths. HTTP(S) and TCP probes confirm that a route and port work, independent of your application traffic. It's useful to distinguish "the partner is down" from "our firewall rule changed".
4. Track certificates on partner links. Mutual TLS credentials on business-to-business links are easy to forget, as no one looks at them until they expire. Use TLS expiry alerts with enough lead time to cover the partner's process as well as your own. See TLS certificate expiry monitoring.
5. Protect yourself, and see it. Timeouts and circuit breakers on external calls should be visible. A retry storm against a struggling partner can worsen your own outage. Rising log patterns such as retrying <*> attempt <*> are a clue, as described in logs and patterns.

Trace context usually ends at that boundary, because a partner may ignore or discard your headers. Whether you should send traceparent to outsiders at all is a reasonable question. It contains no personal data by design, but you may prefer to stop propagation at your edge. The W3C Trace Context guide has the details.

Stations and remote links

Airlines have an unusual network footprint: a central data centre and a long tail of airports with varying link quality, where staff use shared equipment. This raises a few points:

• Group RUM by location or application, because slowness at a station with a poor link looks very different from a global slowdown. Find out how your own applications and user populations can be separated in the data, and ask us how to arrange this.
• Consider the outage direction. If a station's link is down, its browsers can't report anything. Absence of data from a station is itself a signal, and RUM alone can't explain it.
• Hosts. Airport-side Linux servers can have the Linux agent, using the same install script process. Its traffic needs a route back to your installation.
• Time zones. Agents, data centres and flight schedules can all be on different clocks. Keep all your systems on UTC for telemetry, and display the local time where people need it. Your weekly baselines should be interpreted with that in mind, since a hub's morning peak depends on where the hub is.

Sensitive data in airline telemetry

Passenger data appears easily in technical data. Booking references may seem innocuous, but with a surname they often give access to a passenger's whole itinerary. A URL that includes a booking reference and name, a log line that dumps a PNR, or a document number in an API response can each end up in your logs.

• Audit your telemetry for booking references, passport and document numbers, and names. Search a day's sample.
• Remove them at the source or in the collector, as described on the data residency page.
• Card data on booking flows brings PCI DSS considerations. Keep it out of telemetry entirely, and speak with your assessor if the monitoring system might come into scope.
• Passenger data can span many jurisdictions. KVKK, GDPR and others may each apply depending on the route and on the passenger. Discuss this with your counsel, as this page isn't legal advice.

Self-hosting means none of this leaves your network: 0 bytes of telemetry do, and the local model stays on your hardware. It doesn't change your responsibility for what's collected and who can read it. Scoped team views let you limit which teams can see which services.

The operational fit

Airlines often run around the clock, with no quiet night, since it's always a busy hour somewhere. Two properties matter here. Installation doesn't restart workloads, and instrumentation arrives with each pod's next normal restart, so you don't need a special maintenance window for rollout. And alerts can resolve themselves when the issue has passed, which reduces the handover confusion between shifts in a 24-hour operations centre.

English and Turkish UI and assistant are both available. For other languages, ask us.

Runbooks are especially useful in this setting, because the person who responds at 04:00 may be a duty engineer with a wide scope of responsibility and limited familiarity with a specific system. See alerts and remediation. During a major disruption, it's reasonable to suspend automated remediation and run in approval mode, so that automation doesn't compete with human decisions at a time when conditions are abnormal.

When this may not be the right fit

• A small carrier whose core systems are entirely hosted by a supplier has little to instrument. Monitoring the supplier's response from your side, with probes and browser data, may be all you can do, and a full platform would be excessive.
• Native mobile apps are important in this industry. The browser collector doesn't cover them, so talk to us about what you need.
• If a third-party platform forms most of your booking path, the deep parts of the trace will be out of your reach. Check what you can actually see before committing.

Frequently asked questions

How do you monitor an airline check-in system?

Define SLOs on the journeys that matter, such as check-in completion and boarding pass issue, and measure them per station as well as globally. Use real user monitoring on browser-based applications, and link front-end requests to backend traces. Probe the partner links that these journeys depend on.

How should monitoring behave during flight disruptions?

Traffic during disruption is abnormal by definition, so baseline anomalies say little at that point. Focus on SLO burn rate for rebooking and customer contact journeys, and on saturation of the systems behind them. Consider switching automated remediation to approval mode for the duration.

Is Wrentrix suitable for safety-critical aviation systems?

No, that's not what it is for. It is an APM and AIOps platform for IT systems, and we make no claim of aviation certification. Safety-critical systems should remain under their own assurance regimes.

Can I trace requests through a third-party reservation system?

Usually only up to the boundary, because an external party may not continue your trace. You will still see your outbound call's duration, status and error pattern, and that's often enough to show where the delay is. Ask the supplier what they expose on their side.

Do any airlines use Wrentrix?

We don't publish a customer list on this page. The product is designed with regulated industries such as aviation in mind, and that describes the design and not any particular organisation. Write to info@wrentrix.com with any questions about references.