Your dashboard stops at checkout

The fastest travel search in the world is still a claim about a Tuesday six weeks from now. We spend an extraordinary amount of engineering effort on the part of that sentence measured in milliseconds and almost none on the part measured in weeks, and the reason is not that anyone decided the weeks matter less.

The reason is that milliseconds emit and weeks do not.

Observability is shaped like your request graph, not your promise

Every synchronous call you make produces evidence of itself. It has a start, an end, a status code, a parent span and an owner on the org chart. Point any tracing tool at a search path and it discovers structure for free, because the structure is already there in the shape of the request.

Now look at what happens after the confirmation screen. The important events in a travel order are not requests you made. They are things that happened elsewhere, to someone else's system, on someone else's schedule: an airline moved a departure by ninety minutes, a hotel quietly reassigned a room category, a supplier reference you cached became stale, a refund that was authorised did not arrive.

None of those emit anything on your side. They are not slow requests. They are absent messages.

So the dashboard fills up with the part of the system that volunteers information, and everyone reads it as a map of the customer experience. It is not. It is a map of your synchronous code paths, which happen to end at the exact moment the customer's risk begins. Checkout is not the finish line of the transaction; it is the midpoint of the order. Our instrumentation just stops there because that is where the spans stop.

This is Goodhart's law with a twist. The usual version says a measure stops being good once it becomes a target. The travel version is worse: we picked the measure because it was cheap to collect, then reasoned backwards into believing it was the thing that mattered.

The support inbox is not a monitor

Here is the honest architecture of post-booking detection at most travel products, drawn as a timeline against the part everyone instruments.

Read the bottom band as an outage detector and it is disqualifying. Its median detection latency is measured in days. Its coverage is limited to customers annoyed enough to write in, which is a biased sample of the affected population and a small fraction of it. It has no severity classification, no alerting policy and no on-call rotation, and it silently drops every failure the customer never noticed but finance will meet later at reconciliation.

Nobody would accept those properties in a search monitor. We accept them after checkout because the alternative requires deciding, in advance, what should have happened, and that is real design work rather than a library you install.

You cannot page on the absence of a message

This is the crux, and it is why "add post-booking dashboards" as a ticket never works.

An alert on a request is easy: the request arrives, you look at it, you compare it to a threshold. An alert on a non-event requires a record written earlier that says what you expected and when you expected it by. Absence is only detectable against a prior claim.

Which means the instrumentation is not a dashboard. It is a small object your order writes when it makes a promise.

{
  "order_id": "ord_4f21ab",
  "component": "flight:leg-1",
  "expect": "supplier_state_confirms_match",
  "recheck_every": "PT6H",
  "not_silent_after": "P2D",
  "on_absence": "page:supply-oncall",
  "on_divergence": "open:servicing_case"
}

That record is the whole trick. A watchdog with an expiry turns "nothing happened" from an unobservable state into an event with a timestamp and an owner. It also forces a question most order models cannot answer: what did we promise, precisely enough that a machine can check it later?

Five clocks that start with the supplier, not the user

The defining property of a useful post-booking metric is that its clock starts on someone else's action. Request-shaped metrics all start when a user does something, which is exactly why they end before the risk does.

Time to truth is the one to build first, because every other number in the table is downstream of it. You cannot tell a traveller about a change you have not detected, cannot service what you have not modelled, and cannot reconcile money against a state you believe is still valid. Detection latency is the parent metric of the entire post-booking experience, and in most systems it is not a number at all. It is a story about a support ticket.

Promise-kept rate is the one to report upward, because it is the only metric in the set that a non-engineer can be wrong about in public. "Ninety-something percent of orders reached the traveller without a human having to rescue them" is a sentence an executive can act on. A p95 search latency chart is a sentence nobody has ever acted on.

Measurement forces the architecture

Here is the part that makes this worth doing even if you never build a dashboard: you cannot measure divergence without keeping something to compare against.

If a booking is stored as a receipt, a frozen blob of what checkout produced, there is nothing to reconcile. You have no per-component supplier reference to re-read, no recorded expectation to test, no event history to explain how the current state came about. The metric is impossible because the model is missing, and teams usually discover this in the order I have written it: they try to build the metric, and find the object it needs does not exist.

That is a feature of the exercise. Trying to answer "how long until we know" forces stable component identifiers, a supplier reference you can re-read, an event log with causes rather than a status column, and money movements that link back to the components they paid for. Those are exactly the things the order lifecycle needs anyway, and exactly the things refund reconciliation needs at settlement. Measurement is a good forcing function precisely because it fails loudly when the model is wrong.

The honest trade

None of this says latency is unimportant. It converts, it is a real cost driver, and a search that takes nine seconds loses the session. But look at the shape of the two risks. Search latency has well-understood diminishing returns: past a point, another eighty milliseconds changes nothing anyone can perceive. Post-booking failure has an unbounded tail. A slow search costs a session. A schedule change your system learned about from the customer costs the customer, the manual settlement, the support hours, and the story they tell.

So the allocation question is not whether milliseconds matter. It is whether the tenth engineer on the search path is worth more than the first engineer on detection. In most travel products I have seen, that is not a close call, and it stays uncalled because one side of it has a dashboard and the other side has anecdotes.

The customer-facing half of this argument, what those detected states have to look like when a traveller reads them, is post-booking is the trust product. This half is upstream of it: you cannot communicate calmly about a change you found out about last.

The test

Take an order that is confirmed right now, departing in a month. Suppose the airline moves it tonight.

How do you find out? What starts the clock, what stops it, who gets paged, and what is the p95 of that interval across last quarter?

If the answer involves a customer, you do not have a monitor. You have a complaint queue with good response-time metrics, which is a measurement of how fast you apologise.