Xebia · Irish Rail

A 180-Year-Old Railway, Run Like a Modern Platform

Irish Rail's estate spans Azure, AWS and Oracle Cloud, with a home-grown Grafana platform watching 2,400 km of track. Working alongside Xebia, our brief is to tune that estate, give fast-built internal apps one safe path to production, and extend monitoring that already sets a standard.

August 2026
7 min read

Some engagements begin with a rescue. This one begins with respect. Irish Rail is not a struggling estate looking for a saviour: its in-house team built IRIS, an intelligent sensing platform that unifies IoT data from over fifty vendors across roughly 2,400 km of track, and presented it at GrafanaCon 2026 after proprietary bids costing millions were turned away. When the platform you are joining is that good, the job is not to replace anything. It is to make an already strong system faster, safer and easier to build on.

We joined the programme through Xebia, whose rail portfolio runs from Eurail's AWS landing zone to API platforms for Dutch Railways. The work at Irish Rail splits into three strands that feed each other: optimising the existing infrastructure and tooling, building a small unified cloud environment where internally built apps are tested before they touch production, and extending the Grafana monitoring stack that ties the whole railway together.

The estate we walked into

Like most organisations with real history, Irish Rail's technology landscape grew by necessity rather than by diagram, and it is genuinely multi-cloud.

  • Azure carries the enterprise data platform, a lakehouse built around Synapse and Fabric with Power BI on top and SAP feeding it.
  • AWS hosts ticketing, where the Sqills S3 Passenger reservation platform moved from on-premises hosting to SaaS in 2021.
  • Oracle Cloud runs HCM for payroll and workforce management.
  • IRIS, the in-house Irish Rail Intelligent Sensing platform, sits on Azure: Grafana for visualisation and alerting, an MQTT unified namespace as the integration backbone, TimescaleDB for time series, mapped into SAP asset management and ServiceNow workflows, ISA-95 compliant.

Bridges report structural movement, welded rail reports its temperature, pumps and weather stations stream readings, and a three-person team watches a national railway through dashboards they built themselves. That is the landscape. The friction lives where the pieces meet: infrastructure code that has drifted, pipelines slower than they should be, environments that differ just enough to bite.

Tuning what already works

The first strand is deliberately unglamorous: a working platform deserves the same engineering attention as a broken one, because that is what keeps it working. The optimisation backlog is built from measurements, not opinions.

  • Infrastructure as code: consolidating templates, removing drift between declared and deployed state, and making changes reviewable instead of remembered.
  • Pipelines: caching, parallelism and trimmed steps so builds and deployments spend their time compiling and testing rather than waiting.
  • Right-sizing: matching compute and storage to what workloads actually use, so the estate costs what it should and no more.
  • Alert hygiene: quieter, better-routed alerts so the signals that matter are never buried by the ones that do not.

One line to production

The second strand answers a very 2026 problem. Teams everywhere are building internal tools at AI speed, the kind of apps people happily describe as vibecoded, and the temptation is to push them straight to production because they were cheap to make. Cheap to make is not the same as safe to run next to systems a railway depends on. So we are building a small unified cloud environment that gives every internal app the same journey: one track, four stations, no shortcuts.

It works the way a railway already thinks. A release departs the sandbox, and a signal must clear before it enters each block: tests in the sandbox, contract checks against a mocked MQTT namespace in integration, a load probe against a peak-timetable profile in staging, and a progressive rollout watched by Grafana in production. Press Depart below to ride one release down the line and watch the signals clear.

Signal Path · Sandbox to Production
svc p95118 ms
error rate0.12%
mqtt msgs/s4.2k
signals cleared 0 / 4
held at signal
SANDBOX
INTEGRATION
STAGING
PRODUCTION
$ awaiting departure, press Depart
A release rides sandbox to production, one signal per block, with the metrics strip reacting like the Grafana dashboards that watch the real thing

The gate is the feature. The point of the unified environment is not slowing anyone down, it is that promotion becomes boring. When every app rides the same signals, a vibecoded roster board and a serious operational tool earn production the same way, and nobody has to argue about it.

Standing on IRIS, not beside it

The third strand is the one we approach with the most humility. IRIS already does the hard thing: it turned fragmented sensor data from dozens of vendors into a single operational picture, cutting notification for safety-critical events from hours to real time. Our work extends it rather than touching its foundations.

  • Dashboards as code: provisioning new Grafana dashboards and alert rules from version control, so the next asset class comes online with a review instead of a rebuild.
  • New surfaces: wiring the deployment platform itself into IRIS, so releases, environments and pipelines appear beside pumps and bridges in the same operational picture.
  • TimescaleDB care: retention policies, compression and rollups tuned so years of sensor history stay queryable without the storage bill growing like the data does.
  • Alert routing: deeper ServiceNow integration so that what Grafana notices becomes a ticket with context, not just a notification.

How the engagement runs

Xebia's rail engagements follow a recognisable shape: land safely, codify everything, and leave the client's team stronger than you found them. We work embedded with the people who built this estate, and everything we add is documented and handed over as we go, because a platform a national railway depends on cannot depend on consultants.

The measure of success is deliberately modest: infrastructure that drifts less and costs less, internal apps that reach production through signals instead of side doors, and an IRIS that covers more of the railway with the same three people at the wheel.

Railways learned long ago that speed without signalling is just risk in motion. Shipping software is no different: the fastest safe path wins.

Takeaways

  • Respect what works: a strong in-house platform is something to extend, not replace.
  • Multi-cloud by evolution is normal, the value is in smoothing where the pieces meet.
  • Give AI-speed internal apps one gated path to production so cheap to build never means risky to run.
  • Extend monitoring as code, so new dashboards and alerts arrive by review instead of by hand.
  • Hand over as you go: the goal is a stronger client team, not a longer engagement.

Platform grown by necessity, not by diagram?

We tune multi-cloud estates, build gated paths to production for fast-moving internal apps, and extend Grafana monitoring stacks, all documented and handed over to your team.

Talk through your estate
promote.sh
SECURE
cloudxops@rail-platform:~$ ./promote.sh --app depot-roster
# Riding the signal path to production...
[OK] sandbox + integration signals green
[INFO] staging load probe · p95 within budget
[READY] progressive rollout · Grafana watching
$
Signals cleared