Home/Journal/Operations
Operations · · 6 min read

Connected is not the same as working

The dangerous integration failure is not the one that throws an error. It is the one where the status still says connected, nothing is logged, and stock stopped moving four days ago.

Every seller who has run marketplace integrations for a while has the same story. Something stopped working, nobody noticed, and the way it surfaced was an oversell, a late dispatch or a buyer asking where their parcel was.

The status screen said connected the whole time. It was not lying. It was answering a different question from the one that mattered.

The four ways it goes quiet

Authorisation expires. Most marketplace connections are time-limited and have to be renewed in the background. If the renewal fails once, at a moment when nothing was being synced, the failure can pass unnoticed until the next time something needs to move.

Authorisation is revoked. Somebody changes a password, removes an app, or a staff member whose account authorised the connection leaves. Nothing on your side broke; the permission simply is not there any more.

A limit is hit. Marketplaces meter how often anything can call them. Cross a threshold and requests start being refused. Handled well this is a slowdown. Handled badly it looks like a series of unrelated one-off errors.

Or a single operation stops while the rest continues. Orders still come in, stock still pushes, but price updates are being rejected for one category because a required attribute changed. The connection is fine. One thing inside it is not.

Why the status light is usually green

Most integration status indicators answer the question "did the last request succeed". That is a fine question and a poor alarm, because a connection that is doing nothing has no failing requests.

The more useful question is "when did this last actually do something, and was that recently enough to be normal". A channel that has ingested no orders in eighteen hours may be having a quiet day, or may have stopped. Which one it is depends on what that channel normally does, and that is knowable.

What a system should do about it

Renew authorisation ahead of expiry rather than on failure, and treat a renewal failure as an event worth surfacing rather than something to retry forever in silence.

Pace itself against the published limits instead of discovering them. Being refused is information the integration should already have had.

Cap retries. A push that cannot succeed should be parked and shown to a person after a bounded number of attempts. Infinite retry is how a queue of failures becomes invisible.

And keep failures where the work is. A sale that could not be sent, a document that could not be posted, a label that did not come back: each belongs in a list somebody looks at, not in a log somebody would have to think to check.

What to check on your own setup

For each channel you sell on, answer three questions. How would you find out if it stopped ingesting orders, and how long would that take? What happens when the authorisation expires, and has that path ever actually run? And when something fails to send, where does it go, and who looks there?

If the answer to any of them is a person remembering to check, that is the gap. It will hold until the week somebody is on holiday.

Run it on one platform.

14-day trial, no card required. Marketplaces, stock, shipping and accounting in one workspace.