Monitor the integration, not just the server

Most monitoring answers one question: is the machine responding? That is worth knowing, and it is not the question that matters most once you depend on an integration.

Integrations fail in a quieter way. The process is running, the endpoint responds, nothing is on fire — and no bookings have been imported since Tuesday. Nobody gets an alert, because from the server's point of view nothing is wrong.

The failures that produce no error

A credential or token expires, so every call is refused and the integration treats it as nothing to do. A scheduled job is disabled, perhaps during unrelated maintenance. A webhook subscription lapses at the other end. A mapping goes stale because a product changed, so records no longer match anything and are skipped. A notification sender is suspended, so messages are accepted and never delivered.

What these share is that nobody complains. Customers do not report an email or a text they never received, and a record that was never imported leaves no trace to notice.

Watch the work, not the process

The useful signal is whether the expected thing happened. Did the sync import anything in the last period, when it normally would? Did any messages actually go out today? Does the count on our side still agree with the count on theirs?

These are not difficult checks, and they catch an entire class of failure that uptime monitoring cannot see by design. A quiet integration is usually a broken one, and quiet is something you can measure.

Alert on absence, with an honest threshold

Checking that something happened means defining how long silence is acceptable, and that varies: a booking feed might be suspicious after an hour, a weekly report after a day.

Set it to the real rhythm of the work rather than a round number, or the alert gets noisy and then ignored — which leaves you worse off than before, since now there is an alert nobody reads.

Reconcile against something external

The strongest check compares your records against a system you do not control: the platform's own counts, a payout statement, a supplier invoice. If those agree, the integration is working in the only sense that matters.

Run it on a schedule and report the exceptions. It catches the slow divergences that no single-request check can see, and it is the difference between believing an integration works and knowing it does.

A short checklist worth running

For each integration you depend on, four questions tend to expose the gaps quickly. Would you know within an hour if it stopped? Does anything check that the number of records on your side still matches theirs? When did the credentials it uses last get reviewed for expiry? And if it produced nothing at all today, would that look any different from a quiet day?

The last one is the most revealing. If a normal day and a broken day are indistinguishable from the outside, there is no monitoring yet — only hope.

Build the integration so it can be monitored

Some of this is a design choice rather than an afterthought. An integration that records what it did — how many records it processed, when it last ran successfully, what it skipped and why — is one you can check cheaply.

One that writes nothing down can only be inspected by querying both sides and comparing them by hand. The cost difference shows up every time something looks wrong, which over a few years is considerable.

Decide who the alert reaches

An alert nobody owns is not monitoring. Someone has to receive it, be able to act, and be expected to. For integrations we build and host, that is us — which is the point of having them hosted and watched rather than handed over.

Whoever owns it, the test is simple: if this broke right now, how long before a human knew? If the honest answer is measured in weeks, the gap is worth closing before anything else.