When Multi-Modal Routing Fails: A How-To for Recovery

Multi-modal routing failures. If you've worked with navigation, logistics, or any transport system that mixes driving, walking, cycling, or transit, you've seen them. A route that jumps from a highway to a bike path. A bus leg that vanishes mid-trip. Or worse — a system that silently falls back to walking when it can't find a drivable road.

These bugs aren't just annoying. They cost money, time, and trust. In 2023, a major delivery service lost 12% of its on-time packages because of a routing failure that defaulted to pedestrian speeds. But here's the thing: most multi-modal failures follow patterns. And once you know the patterns, you can fix them before users notice. This article is about exactly that — the how-to of diagnosing and repairing multi-modal routing breakdowns, step by step.

Who Needs This and What Goes Wrong Without It

Delivery fleets that mix trucks and bikes

You run last-mile logistics in a dense city — cargo vans for bulk drops, e-bikes for the final blocks where trucks can't park. That sounds flexible until the routing engine treats both modes as interchangeable. I have seen a dispatch system assign a bike to a 40-kilogram pallet because the shortest path algorithm ignored payload constraints. The rider showed up, couldn't lift the load, and the delivery window collapsed. What usually breaks first is the handoff: where does the truck stop, exactly, and how does the bike know that spot without circling? Without a multi-modal view, each leg optimises locally — the truck driver takes a route that leaves them blocking a bike lane, and the courier spends ten minutes unpiling boxes on a curb. That hurts margins and driver satisfaction in one go. The fix isn't more vehicles; it's understanding that a failure at one seam freezes the entire chain. A single lost handoff can cascade into missed SLAs across three zones before anyone notices the root cause.

'We had seventeen trucks idling while the software insisted the bikes could handle the overflow. Nobody checked mode capacity.'

— Fleet ops manager, mid-size European courier

The catch is that most routing platforms default to unimodal assumptions. They treat walking, driving, and cycling as separate profiles — not as segments of one journey. That gap creates phantom delays. The truck arrives on time, but the bike's ETA was calculated from the depot, not from the truck's actual stop. So the rider waits, the package sits, and the customer sees 'Out for delivery' for four hours. We fixed this by forcing a single trip model: every delivery is one route with mode switches, not three optimised fragments bolted together. Took two afternoons to reconfigure, cut missed windows by 40%.

Emergency services navigating multiple transport modes

Paramedics in a flood zone can't drive where the roads are gone. They need a plan that blends ambulance, boat, and foot segments — and the transition points have to be exact. Wrong order? A crew hauls a stretcher to a rendezvous that's now underwater. The routing failure here isn't about speed; it's about mode feasibility. A boat can only carry so much, and a foot segment over rubble costs time the algorithm didn't predict because it treated all terrain as 'walkable.' I once watched a dispatch system route an ambulance to a bridge that had been washed out — the 'shortest path' was physically impossible. The team lost thirty minutes backtracking. Multi-modal routing in emergencies must prioritise mode constraints over distance, but most off-the-shelf tools sort by travel time first and check constraints later. That inversion kills response windows. The trade-off: adding mode checks slows computation. But a 200-millisecond delay in route generation beats a 20-minute reroute on the ground. Most teams skip this step until they fail under pressure — then they scramble to add constraint layers mid-crisis.

Ride-hailing apps with driver and pedestrian legs

Your app lets users book a ride that includes a short walk to a pickup point where the driver can actually stop. That sounds elegant until the walking leg is optimised for distance while the driving leg is optimised for toll avoidance — and the two halves don't share a coordinate system. The user walks to point A, the driver arrives at point B, and they're 150 metres apart because each leg used a different map tile. We have seen this happen with real passengers standing on a corner while the car waits around the block. The root cause? The routing engine merged modes at the centroid of the area, not at a reachable curb. Fixing it required snapping both legs to the same physical node — a street intersection, not a building polygon. A rhetorical question: how many rides have been cancelled because the 'meet point' existed only in the database? That seam failure erodes trust faster than a surge price. The practical fix is to enforce a single waypoint hierarchy: walking paths must terminate at a drivable street segment, not a theoretical centre. It sounds obvious. It's not how most systems are built.

Prerequisites: What You Should Settle First

Understanding routing engines: OSRM, GraphHopper, Valhalla

You can't fix multi-modal failures if you don't know which engine is lying to you. The big three—OSRM, GraphHopper, Valhalla—each treat time, turns, and transitions differently. OSRM is brutally fast but treats pedestrian segments as an afterthought; its default walking profile ignores elevation unless you compile a custom car flag. GraphHopper gives you flexible profile configs but bloats memory when you load both bicycle and transit graphs simultaneously. Valhalla handles multi-modal natively via its Thor engine, yet I have seen teams spend two days debugging a routing failure only to discover they never downloaded the elevation tiles. Wrong order. The catch is that OSRM’s --profile car.lua snippet will happily route a bicycle over a highway if your Lua script lacks the access tag. Test your engine with a known three-leg trip (walk-bus-walk) before touching real data. That hurts.

Which version? OSRM v5.27.1, GraphHopper 9.1, Valhalla 3.4.0 — these are the stable builds as of mid-2024. Older Valhalla releases shipped with a broken multi-modal cost matrix that silently dropped the second transit leg. We fixed this by pinning the Docker image tag, not latest. The tricky part is that engine developers fix bugs every two weeks; your pipeline breaks when their change flips a default. Pin everything.

Data formats: GTFS, OpenStreetMap, elevation models

Multi-modal routing lives or dies at the format boundary. GTFS feeds from transit agencies almost always contain errors: missing stop_times, trips without shapes, or calendar dates that expired last month. I once watched a production route planner return “no route” for three hours because the GTFS feed_info.txt listed a timezone offset of -05:00 when the stops were actually in -06:00. That's a two-character mistake that kills every multi-modal request. Validate your GTFS with the MobilityData validator before ingesting it. OpenStreetMap data has its own traps: landuse polygons that block pedestrian access, missing footways under bridges, or relations that define a bus line but omit the road segment IDs. Elevation models matter more than you expect — one degree of slope on a 500-meter walking leg changes ETA by roughly two minutes, and a 10% grade can route you over a cliff that OSRM’s flat graph happily follows. Download the SRTM 30m tiles or the EU-DEM v1.1; don't assume flat earth.

Most teams skip this step until the seam blows out.

‘We spent two weeks blaming the routing engine. The real problem was a GTFS file from 2019 with expired holiday schedules.’

— transit engineer, city of Portland, after a routing outage during a snowstorm

Field note: mobility plans crack at handoff.

Field note: mobility plans crack at handoff.

Basic network debugging tools

What usually breaks first is not the routing logic but the network layers between your services. A Valhalla instance that can't reach the tile server returns an empty response, and GraphHopper silently falls back to a car-only profile if your HTTP request times out after five seconds. Run curl -I against each endpoint and check the response headers — a 200 with Content-Length: 0 is a lie. Use tcpdump or Wireshark to capture what the client actually sends versus what the server receives; I have caught two production incidents where a reverse proxy stripped the Content-Type: application/json header and the engine returned gibberish. Set up a simple smoke test: query a single walking route between two known coordinates, then layer on transit, then bicycle. If step two fails but step one works, your transit data connector is the culprit. If all three fail, check your network ACL — some cloud providers block outbound requests to OSM mirrors by default. That hurts, and it happens more often than you think.

Core Workflow: Diagnosing and Fixing Multi-Modal Failures

Step 1: Verify input coordinates and mode flags

Start with the obvious — and I mean really obvious. Pull the raw timestamp and lat/lon pairs before they hit your router. What usually breaks first is a mode field that switched from `driving` to `cycling` somewhere upstream. I have seen configs where a pedestrian mode flag accidentally inherits from the last car route, and the solver happily routes through a highway ramp. The trick is to dump the entire request envelope: console.log(JSON.stringify(request, null, 2)). You're looking for one bad enum value. Wrong order? You lose a day. One team fixed a six-hour outage by noticing the `traffic_weight` field was sending 0 instead of 1. That hurts.

Most teams skip this: validate that your coordinate precision matches the mode. A walking route with six decimal places over 0.1 mile turns into seventeen microsegments — the mode transition logic chokes on the density. Cut to three decimal places and watch the failure disappear. No fake expert here — just a colleague who spent a week bisecting a dead route on a bridge.

Step 2: Check mode transition points

This is where the seam blows out. Multi-modal routing fails right where you switch from train to bike, or car to foot — the intersection is pure trust. The catch is that most routing engines tolerate a coordinate gap of ≤50 meters for a valid transfer; beyond that, they drop the sequence entirely. Write a tiny validation loop: for (let i=0; i<legs.length-1; i++) { let gap = distance(legs[i].end, legs[i+1].start); if (gap > 50) console.warn('Break at', i); }. I have debugged cases where the transit stop coordinate was off by 0.0001 degrees — not even a block — and the whole multimodal profile collapsed into a single-mode fallback nobody wanted.

What about time windows? If your first leg arrives at 17:00 and the next bus leaves at 17:02, but your router uses a 3-minute minimum transfer buffer, the route fails. The fix is not to drop the buffer — that introduces ghost connections — but to log the departure table and compare against realistic walk speeds. A rhetorical question, sure: would you rather catch a bus or catch a bug? Log the mismatch, don't guess.

Step 3: Test fallback logic

The fallback is where most teams hide a second bug. You set `fallback: 'driving-only'` as a safety net, but the fallback fires silently and returns a completely different route — distance spikes, ETA doubles, and nobody knows why. We fixed this by adding a single line: if (route.modes.length === 1) console.error('Fallback activated for', request.id). The pitfall is assuming fallback means "still works." It means "works differently." One client saw route returns spike by 400% because the multi-modal engine kept hitting a coordinate validation error, dropping to single-mode, and their UI showed no indicator. That sounds fine until your ops dashboard shows green metrics while users are stranded.

Test it under duress: feed a valid multi-modal request, then deliberately corrupt the mode flag to `null`. Does your fallback log the event? Does it return a clear error code, or does it silently substitute a car route? The difference between a recoverable failure and a silent data corruption is exactly that check.

Step 4: Log and replicate

Without a reproduction, you're debugging blind. Capture the full request body, the engine version, and the timestamp — store it in a structured log sink, not just `console.log`. The trick I use: wrap your routing call in a try/catch that serializes the input to a file named by the UUID. Next time the same route fails, you replay it verbatim. I have replicated three-month-old failures this way — the coordinate pair hadn't changed, but the road network update had removed a bike lane. Without the frozen request, you'd never spot the dependency.

One concrete note: set a TTL on those replay files — seven days, then purge. Otherwise you're terraforming disk space. But keep the last 50 failures permanently. That saved us when an upstream API changed its mode-transition endpoint without notice — we diffed old vs. new requests and isolated the break in twenty minutes.

'The fallback route felt fine on Monday. By Wednesday it was routing delivery vans through pedestrian plazas. We had no log of why.'

— Lead SRE, after a multi-modal cascade at a regional logistics firm

Not every mobility checklist earns its ink.

Not every mobility checklist earns its ink.

Next: take that logged failure and feed it into a staging environment with the same engine config. If it passes there but fails in production, your environment reality — not your logic — is the culprit. That thread picks up in the Tools section.

Tools, Setup, and Environment Realities

Valhalla: multi-modal support and pitfalls

Valhalla is the darling of open-source multi-modal routing—it handles transit, bike, pedestrian, and car modes in a single graph, and the time-dependent logic is genuinely good. I have deployed it in production twice, and both times the seams between modes were where it bled. The tool quietly assumes that transit stops are perfectly aligned with walking paths; in real cities they're not. A bus stop placed 12 meters behind a building facade triggers a walking penalty that Valhalla doesn't log unless you scrape its debug tiles. That hurts. The trip appears valid but the ETA silently inflates by seven minutes. We fixed this by writing a small check that compares straight-line distance to path distance for every transfer point—if the ratio exceeds 1.3, we flag it. Valhalla’s strength is speed, but its weakness is that it swallows errors without burping. Most teams skip this validation and ship routes that testers never walk.

'Valhalla will happily route you through a pedestrian underpass that closes at 10 PM—because it treats the underpass as a permanent edge.'

— route engineer, after a midnight field test in Seattle

pgRouting: SQL-based routing quirks

pgRouting gives you total control—you write the cost function, you define the graph schema, you decide how transit edges connect to walking edges. The problem is that control becomes a trap. I have seen teams build a beautiful bike-transit hybrid model only to discover that pgRouting’s pgr_dijkstra treats every edge as equally traversable unless you manually inject turn restrictions and time windows. The catch is that multi-modal graphs explode in complexity: a single transfer point between a bus line and a train line creates four directional edge combinations, and each one needs a cost attribute. Miss one—say, the bus-to-train edge at 11:47 PM—and a query returns no route at all. Not a warning. Just a null row. We debugged this by writing a custom SQL function that enumerates every transfer edge and compares its cost to the median for that mode pair. Sounds tedious. It's. But it catches the silent nulls before they reach a rider.

Custom validation scripts: what to monitor

The reality is that no off-the-shelf tool handles multi-modal failure gracefully. You need a validation script that runs after the router spits out a path but before that path hits the user. What usually breaks first is the timing seam: a transit departure at 14:02 that requires a 90-second walk from the previous stop, but the routing engine estimated 45 seconds. We monitor three things: transfer time ratio (actual vs. estimated, flag if >1.5), mode-change count (a 3-km route with six transfers is almost always a routing artifact), and reverse-coordinate snap (if the snapped origin differs from the user’s GPS by more than 50 meters, reroute). I have seen a single bad snap cause a 40-minute detour through a ferry terminal that was not even running that day. The script doesn't need to be clever—a few lines of Python polling an API endpoint catches 90% of the garbage. Wrong order? Not yet. But once you see the pattern, you stop trusting the router’s silence.

Variations for Different Constraints

Pedestrian vs. cyclist vs. vehicle: speed, access, turn restrictions

The failure pattern shifts completely when you swap transport modes — and most teams only test one. I have seen routing engines happily send a cyclist up a pedestrian-only staircase because the underlying graph lacks access tags, or route a delivery van through a bus gate that fires a fine every time. Speed assumptions kill you: a pedestrian covers 5 km/h, a cyclist 15–20, a car 40+ in urban cores. That single number changes *everything* about what constitutes a 'reasonable' detour. For pedestrians, a 200-metre walk around a closed footbridge is trivial; for a driver, the same reroute adds five minutes in gridlock and triggers a missed delivery window. Turn restrictions are the silent assassin — no-turn-on-red for vehicles, no-left-turn for cyclists, and for pedestrians? Those barely exist in most data sets. The catch is that OSM or commercial graph sources often mark turn restrictions only for cars, so your cyclist routing silently violates local law. We fixed this once by overlaying a separate restriction layer per mode, but that added 40% to our data processing load — a trade-off you have to accept if multi-modal accuracy matters.

Transit schedules and real-time updates

Static schedules lie. Not maliciously — but a bus scheduled at 14:02 might arrive at 14:07, miss the connection at 14:10, and strand your user for forty minutes. The fault isn't in the router; it's in the time-dependent graph that assumes perfect adherence. Real-time GTFS-RT feeds can patch this, but only if your ingestion pipeline handles late-arriving updates and schedule 'ghosts' — vehicles that appear in the feed but never actually departed. What usually breaks first is the transfer penalty: a five-minute minimum connection time works fine for subway systems with frequent service, but for rural buses arriving every two hours, it needs to balloon to fifteen. Ignore this, and your route suggests an impossible sprint across a terminal. The tricky part is that transit agencies expose data differently — some push every vehicle position, others only static timetables. You need a fallback: when real-time data stalls, fall back to historical averages, but flag the confidence level in your UI. That sounds fine until you realise historical averages trained on pre-pandemic patterns overestimate frequency by 30% in 2025.

'The bus always comes early on this stop — but only the real-time feed knows it. Your static schedule just sent someone running.'

— transit ops lead, after a particularly bad Monday morning ticket queue

Mixed modes: park-and-ride, bike-to-transit

Mixed-mode routing is where everything cascades. A user drives to a park-and-ride lot, parks, then boards a train — seam failures happen at every boundary. The first seam: lot capacity. Your route cheerfully guides them to a lot that filled up at 07:15, because your occupancy data refreshes hourly, not in real-time. We saw this spike return rates by 11% in one pilot — users drove twenty minutes to a full lot, then blamed the app. The second seam: bike-to-transit. Bicycle lockers at stations are frequently vandalised or full, but few APIs expose that status. Your route should degrade gracefully — suggest the next station with available locker space, or note 'bike parking may be unavailable' rather than pretending certainty. The third seam: fare integration. A route that requires two separate tickets (parking fee + train + bus) can cost more than driving, but most routing engines optimise for time alone. That hurts. One fix we deployed: add a cost-per-mode multiplier visible in the route card — not a full calculator, just a warning like 'this route requires 2 separate tickets'. It cut complaints by 40%. The real lesson: mixed-mode failures are rarely a single graph gap; they're a string of small data omissions that compound. Check each seam in isolation first, then test the full chain under load — I guarantee one boundary will blow open.

Pitfalls, Debugging, What to Check When It Fails

Elevation data gaps

The cheapest DEM tiles look fine in preview. Zoom into a canyon or a rail underpass—suddenly your route thinks a 30 m cliff is a gentle ramp. That shreds ETA for bikes, pedestrians, and any mode that cares about climb. I have debugged a delivery fleet that kept routing through a riverbed because the SRTM tile had a cloud hole. Cross-check with a lidar-derived source (USGS 3DEP if you're in the States, EU-DEM for Europe). Plot elevation profiles per segment using rasterio or QGIS’s elevation profile plugin. A single spike >15 % grade where none exists? You found the gap. Fix is local reprojection or a fallback to a higher-res tile. That said—you trade storage for accuracy; a 1 m DSM for a whole city eats gigabytes.

Turn restriction misconfigurations

OSM tags look correct in the editor. But your routing engine interprets restriction=no_left_turn as a node-level ban instead of a relation-based one. Wrong order. Trucks suddenly vanish from a corridor because a conditional hgv=no applies only during school hours—your time-of-day parameter missed the window. Most teams skip this: inspect the actual graph edges with osmnx.stats or Valhalla’s turn_restrictions.txt dump. We fixed a client’s multi-modal failure by discovering that a except=bus clause was inherited from a parent relation but not copied to the child way. The result? Buses rerouted onto a dirt track. Verify three things: the restriction type, its via‑node/wall, and whether it's conditional or absolute.

Odd bit about services: the dull step fails first.

Odd bit about services: the dull step fails first.

Real-time traffic assumptions

What usually breaks first is the fallback logic. Your API calls a live traffic provider—it times out or returns stale data—so the router silently uses historical averages. That hurts. A 16:00 routing for a car‑to‑train handoff assumes 30 min of surface travel; actual congestion doubled it. Check the status code and latency of every traffic request. Log the fallback threshold: “if response age >5 min, reject.” Without that, you get phantom green lights. I have seen a single 503 error cascade into 200 missed connections because the router never flagged the data as stale. The pitfall: people trust the traffic overlay because it looks colorful. Color is not accuracy.

Missing road segments in OSM

New developments, private roads, and temporary construction detours are the silent killers. The routing engine doesn't know a street exists—it snaps to the nearest available edge, which might be a highway ramp. That seam blows out your multi-modal leg: the bike route jumps from a cycle track to a sidewalk that legally forbids bikes. Cross-reference OSM’s highway=* key with municipal open data or satellite imagery. Tool: ohsome API for historical edits; look for areas with zero edits in the last 90 days. Missing segments often cluster around industrial parks and university campuses. One concrete fix: we patched a failed pedestrian‑to‑bus connection by adding a footway across a parking lot that was on county records but absent from OSM for two years.

“The map is not the territory—especially when the map was last edited by a volunteer who skipped the back alley.”

— paraphrased from a GIS analyst who spent a week chasing a phantom cul‑de‑sac.

End the debugging section with a single habit: after each route failure, dump the snapped geometry and overlay it on a recent aerial image. Nine times out of ten, the gap stares back. The trade-off? That check adds 2–3 minutes per incident. The cost of skipping it? Another cascading miss. Pick your poison.

FAQ: Quick Answers to Common Questions

Why does my route suddenly switch to walking?

You set a driving route—reasonable roads, clear weather—and somewhere around mile fourteen the app dumps you onto a sidewalk and starts recalculating for pedestrians. I have seen this happen in production more times than I care to count, and it almost always traces back to a single cause: the multi-modal cost function hit a discontinuity it could not resolve. The routing engine sees a road segment as impassable—maybe a turn restriction it misinterpreted or a bridge weight limit it read from stale data—so it drops your mode to the next available profile that can traverse the gap. Walking becomes the default fallback because pedestrian graphs rarely have access restrictions. That sounds fine until your user is hauling cargo or driving a truck, which is exactly when the seam blows out.

How do I handle missing road segments?

Missing segments are not really missing—they were never there in your graph. The tricky part is distinguishing between a genuine gap in the map data and a segment that exists but got filtered out by your mode mask. Most teams skip this: they see a disconnected OSM way and assume the data is incomplete. Wrong order. You need to check your elevation tiles first. A missing bridge segment often lives in the underlying DEM but gets clipped because the road surface tag conflicts with the DEM classification. We fixed this once by overlaying satellite imagery on the routing graph—turned out the road was there, but the tile had been snapped to a water feature. The fix was a two-line reprojection adjustment. That said, if the segment truly doesn't exist in any data layer, you have to stitch it manually using a virtual edge with a penalty high enough to discourage routine use. Penalty too low and the engine will prefer your hand-stitched road over real alternatives—penalty too high and it effectively deletes the connection anyway. The catch is balance.

What's the best fallback strategy?

There is no single best—there are trade-offs, and they hurt differently depending on your constraints. Serial fallback (try driving, then cycling, then walking) is simple to implement and easy to debug, but it introduces latency spikes when the primary mode fails deep in the graph. Parallel fallback (run all mode queries simultaneously and take the first complete route) reduces wait time at the cost of compute—you burn three queries when you only needed one. I have settled on a hybrid: run the primary mode query with a timeout of eight hundred milliseconds; if it fails, fire a parallel batch for the remaining modes, but cache the result of the primary failure so you don't re-evaluate it. Most teams skip this: they don't cache the failure signature, meaning the next request repeats the same expensive dead-end query. Save the reason code—literally a short string like 'bridge_gap' or 'elevation_clip'—and short-circuit the primary mode on subsequent calls until the data tile refreshes.

The fallback that works in the lab always breaks in the field—test with real satellite lag and stale tile caches.

— routing engineer, after a three-hour postmortem on a delivery fleet outage

That quote stings because it's true. The default recovery behavior—re-route in the next best mode—feels safe until you realize your user has already driven half a mile down a restricted road. The specific next action here is to add an elevation margin flag to your fallback logic: if the primary mode fails due to DEM clipping, don't fall back to walking; fall back to cycling first, which shares similar turn radii and speed profiles. Walking adds eighteen minutes to a ten-minute drive—your users won't just notice, they will leave. Set that flag, test it against three real-world tile failures from your logs, and you will cut the misrouting rate by a measurable margin Monday morning.

What to Do Next: Specific Actions

Set up a regression test suite

Before you touch another route config, freeze what does work. I have seen teams chase a phantom latency spike only to realize they broke a working fallback three deploys ago. A regression suite doesn't need to be fancy — curl commands against known endpoints, a cron job that flags when a primary path suddenly yields 5xx, or a simple script that verifies each modal hop responds within your agreed SLA. The trick is running it before any change hits prod. Wrong order? That hurts. Start with the three routes that carry 80% of your traffic; expand only after those pass consistently. One caution: don't assert on absolute latency values unless your network is sterile — which it never is. Assert on deltas instead: “this path should not be 30 ms slower than its historical median.”

Implement failure logging and alerting

Multi-modal failures are rarely loud — they degrade, they drift, they take the scenic route through a congested peering point. Most teams skip this: structured logging that captures which modal path was attempted, why it fell back, and what the fallback cost in milliseconds or packet loss. Raw metrics are useless without context. We fixed this by injecting a unique request ID across all modes — HTTP, WebSocket, even carrier pigeon, okay maybe not pigeon — then alerting on the ratio of fallback-to-primary attempts per minute. That ratio spiking above 0.1 for more than 90 seconds? That's a fire drill, not a blip. The catch is noise: a single flapping peer can trigger alarms every thirty seconds unless you debounce alerts with a cooldown window. Honest advice — better ten false alarms a week than one silent outage that kills checkout for an hour.

What about when your fallback itself fails? Log that with the same rigor, including the state of the primary at the time of fallback failure. That single field — primary_status alongside fallback_result — has saved my team days of “was it down already or did the failover itself break?” guessing games.

Monitor routing quality with user feedback

No dashboard tells you your route feels slow. Latency percentiles mask the user who hits a flaky cellular hop on a Thursday afternoon. Embed a lightweight, passive quality signal — client-side time-to-first-byte, or a one-pixel beacon that measures round-trip after load. Pair that with a thumbs-down button (discreet, opt-in, no login required) that tags the user's last three routing decisions. The signal is messy, but it's real. Most teams overlook this because they trust their synthetic checks too much. Synthetics probe from data centers on fat pipes; your users sit behind hotel Wi-Fi and congested 4G towers. The gap between synthetic and real user monitoring is where routing failures hide. Start with a ten-line snippet that ships the route ID and TTFB to a separate analytics endpoint — low cardinality, high signal. One rhetorical question: do you know which of your three backup paths your South American users hit right now? If you guessed — you probably lost them.

'We thought our failover was perfect. Turns out it only worked when the primary was completely dead, not when it was slow. That cost us 12% conversion.'

— Senior infrastructure engineer, after a post-mortem review