When Your Vendor Has an Outage, Your Users Are Having Yours

A partner we route execution to had a bad afternoon recently. Not an outage in the clean sense, which would have been easier. Things were slow, then fine, then slow again, and a share of requests were completing late enough that people assumed they had failed.

Our own systems were healthy the entire time. Every dashboard we own was green. And from where our users sat, our product was broken.

That gap between what we could see and what they experienced is the part worth writing about, because the orchestrator model is now how most small technology companies get built, and this is its bill arriving.

Routing moves execution, not accountability

We build the interface, the wallet and the connective tissue between chains. We route perpetuals to Hyperliquid via builder codes and prediction markets to Polymarket. That is a deliberate decision, it is the only way three people ship this much surface, and I would make it again.

What that decision does not do is transfer responsibility. The user chose us. They have never heard of the components underneath and they have no reason to care about them. When something takes ninety seconds that should take five, the company they are annoyed at is the one whose interface they are looking at.

Any technology leader routing meaningful functionality should be clear-eyed that they have bought capability and kept liability. Those are separate ledgers and only one of them appears in the integration estimate.

Status pages are the wrong instrument

Our first mistake was reasonable and wrong. We watched our partners' status pages.

A status page is a communication tool. It reflects what a vendor has decided to declare, on their timeline, at a granularity that suits them. Partial degradation frequently never appears on one at all, because it is genuinely hard to characterize and nobody wants to raise a flag over something that resolves in twenty minutes.

We now measure the partner from inside our own user's path instead. Synthetic requests that do exactly what a real user does, timed end to end, alerting on latency distribution rather than on failure. It tells us something is wrong well before anyone declares anything, and occasionally it tells us something is wrong when nothing is ever declared at all.

This is the single change I would recommend to anyone running a routed architecture. Instrument the path, not the provider.

What we tell users, and what we refuse to do

There is a strong pull toward one of two bad messages during someone else's degradation. The first is silence, hoping it resolves before anyone notices. The second is deflection, explaining at length that this is an upstream issue with a third party, which is true and reads as an excuse because it is being used as one.

What we settled on is narrower. Name the exact thing that is slow. Confirm we are seeing it on our side, so nobody wastes twenty minutes wondering if it is their connection. Then the part that actually matters to a person with money in flight: did their action complete, yes or no, and if we do not know yet, say that we do not know yet. Upstream gets mentioned as context. It never gets used as the reason they should stop being annoyed. Nobody is owed an architecture lesson. They are owed a straight answer about whether their money moved.

The thing we will not do is show a generic error that leaves someone unsure whether an irreversible action happened. That ambiguity is worse than the delay by a wide margin.

The rule we adopted afterwards

Never route anything whose failure you cannot detect independently of the provider telling you.

It sounds obvious written down. It has real teeth in practice, because it disqualifies integrations that are otherwise attractive. If a capability is a black box that only reports its own health, you are not operating it, you are hoping about it. Either you build a way to observe it from the outside, or you accept that your users will discover its problems before you do.

We have turned down one integration on exactly this basis. It was faster and cheaper than what we chose instead. The deciding question was not which was better on a normal day; it was which one we could tell the truth about on a bad one.

Where this leaves the orchestrator model

I am not arguing against routing. Building everything yourself replaces vendor risk with execution risk, and for a team of three that trade is not close.

The honest framing is that routing narrows what you build while widening what you must watch. Those move in opposite directions, and the second half rarely appears in the plan. Teams budget the integration and forget that they have just taken on a permanent monitoring and communication obligation for a system they cannot fix.

Plan for the afternoon when a component you do not control is slow, your dashboards are green, and your users are annoyed with you. That afternoon is coming, and how it goes is decided months earlier by whether you can see the problem and whether you have already worked out what you are willing to say.