For businesses whose systems are connected and unwatched

Integration Monitoring: The Part Everyone Skips Until It Costs Them

Integrations rarely announce their failure. A token expires, a vendor renames a field, a file arrives empty, an endpoint starts returning success for records it silently drops. Nothing crashes. Orders simply stop arriving in the accounting system, and the first person to notice is whoever reconciles at month end, three weeks later.

Monitoring an integration is not the same as monitoring a server. Uptime tells you the connection answered. It does not tell you whether yesterday’s two hundred orders became two hundred invoices. This page covers the failure modes that hide, the checks that catch them, what a support arrangement should actually promise, and what it is reasonable to pay for.

Book a Support Review (03) 9003 0111

Realistic ROI

Days to weeks

Typical time to notice an unmonitored failure

Usually discovered at reconciliation rather than by anyone watching the integration

20 to 40%

Of integration total cost is running it

Rough guide over a few years, and the part most often left out of the original quote

Same day

Reasonable alerting target for a failed flow

For anything touching orders, stock or payments, sooner is better and overnight is not

1 to 5%

Of records will be genuine exceptions

Realistic in most stacks, so the question is where they queue, not how to eliminate them

Four Layers of Checking, and Why One Is Not Enough

Each layer catches a different class of failure. Most businesses have the first layer, sometimes, and none of the others.

Is it running at all

The simplest layer. Every scheduled flow reports that it ran, and an alert fires when an expected run does not appear. This catches the disabled schedule, the expired credential and the server that stopped, and it is the only layer most businesses have. On its own it is comforting and misleading, because an integration that runs successfully every hour while processing nothing looks perfectly healthy.

Is the volume normal for this hour

You know roughly how many orders arrive on a Tuesday afternoon and how many invoices should post overnight. When the number drops to zero, or triples, something has changed, and an alert on the deviation catches whole classes of silent failure that individual record checks miss. Anomaly thresholds need a seasonal profile in retail, because November is not October.

Do the two systems agree

The layer that actually protects the business: a daily reconciliation that counts records and sums values on each side and reports the difference. Two hundred and forty orders on the store, two hundred and thirty eight invoices in the ledger, and here are the two that did not make it. This turns a vague worry into a two line report that finance can act on.

What happens to the ones that failed

Failures need somewhere to go and a way back in. An exception queue holds each failed record with its reason, its payload and its timestamp, and once the cause is fixed the items are replayed rather than re-keyed. Without replay, every incident becomes a manual data entry project, which is how businesses end up with parallel spreadsheets tracking what the integration missed.

The Failure Modes Worth Designing For

These six account for the overwhelming majority of integration incidents. None of them announce themselves.

Auth failure

Credentials expire

Tokens expire, refresh flows break after a vendor security change, a password rotates, and the staff member whose login was quietly used to authorise the connection leaves the business. The flow starts failing authentication at three in the morning. Monitoring should alert on the first failure, and the design should use a service identity rather than a person so the departure of an employee is not an outage.

Schema drift

A field changes shape

A vendor adds a required field, renames one, changes a code list, or tightens validation. Sometimes there is a release note, often there is not. The integration either errors loudly, which is the good case, or writes an incomplete record that looks fine until someone reads it. Validation on both ends and alerting on unexpected values is what turns the bad case into the good one.

Half written

Partial success

The order header posts and the lines fail. The invoice is created and the payment allocation is not. The response says success because the first call succeeded. These are the hardest failures to find later because both systems believe they are correct. The answer is a completion check per business transaction rather than per API call, and a reconciliation that compares totals rather than counts alone.

Queue depth

Throttling and backlog

Vendor limits pace how many calls you may make. When volume spikes, the queue grows, and a queue that grows faster than it drains eventually looks identical to a stopped integration. Queue depth and age of the oldest waiting item are the two numbers worth alerting on, and they should be checked against peak trading rather than a quiet Wednesday.

Double posting

Duplicates from retries

A timeout on a call that actually succeeded, followed by a retry, creates a second invoice or a second order. Every write needs a stable reference so a repeat updates rather than duplicates, and monitoring should look for duplicate references arriving within a short window. Duplicates are worse than gaps because they get paid, picked or shipped before anyone questions them.

Wrong window

Time and calendar mistakes

Daylight saving shifts in New South Wales, Victoria, South Australia, the Australian Capital Territory and Tasmania while Queensland, Western Australia and the Northern Territory stay put, and half the vendor systems report in universal time. A nightly job that runs at the wrong hour double counts or skips a day, most visibly at the start and end of daylight saving and at the end of a GST period. Store timestamps unambiguously and test the boundaries deliberately.

What Good Monitoring Catches, and When

Task	Traditional	Monitored Properly	Notes
Overnight invoice posting stops	Found at month end	Alert by 7am, replayed same day	The volume check catches this even when the flow reports success, because zero is not a normal night.
Store credential rotated by IT	Silent auth failures for days	First failure raises an alert	Service identities and a documented owner prevent most of these before they happen.
Vendor adds a required field	Records rejected, nobody told	Exception queue fills, owner notified	The queue keeps the payloads, so replay after the fix costs minutes rather than a data entry week.
Peak day rate limiting	Looks stopped, panic ensues	Queue depth alert with drain estimate	Knowing it is a backlog rather than an outage changes the response entirely.
Duplicate order from a retry	Picked and shipped twice	Blocked by a stable reference	Cheaper to design in at build than to unpick from a warehouse and a ledger later.
Freight file arrives empty	Processed as no despatches	Empty payload treated as suspect	An empty file is a legitimate result on a public holiday and a red flag on a Tuesday. Calendars matter.
Totals drift between systems	Argued about at reporting time	Daily count and value reconciliation	A short daily difference report ends the recurring debate about which system is right.
The person who built it leaves	Nobody can safely touch it	Runbook, access and logs handed over	Documentation is a deliverable, not a favour. It is also what makes a support arrangement transferable.

Where Support Arrangements Fall Short

A dashboard nobody opens is not monitoring

Passive dashboards depend on someone remembering to look, and nobody looks at a green screen. Alerts must be pushed to a named person through a channel they already watch, with a severity that reflects the business impact, and there should be a scheduled report that arrives even when everything is fine, so silence is never ambiguous.

Alerting on everything, which trains people to ignore it

The opposite failure. If every retryable timeout raises an alarm, the alarms become noise within a fortnight and the real incident is missed among them. Alert on outcomes rather than events: a flow that has not completed, a queue that is not draining, a reconciliation that does not balance, an exception queue that is growing. Everything else belongs in the log.

No replay path, so incidents become data entry

If failed records are lost rather than queued, then every incident is followed by someone re-keying whatever the integration missed, usually without knowing exactly which records those were. Insist that failed items are retained with their payloads and that replay is a supported operation, tested before you need it rather than improvised during an outage.

Support that is defined in hours rather than outcomes

A retainer that promises a number of hours a month tells you nothing about how quickly a broken order flow gets fixed. Ask for response targets by severity, who is on call and when, what happens outside business hours, whether vendor interface changes are covered, and what is explicitly excluded. Vague support is what turns an incident into a quoting exercise while orders pile up.

Logs that keep more personal information than they should

Record level logging is essential for support and is also a collection of personal information under the Privacy Act 1988 and the Australian Privacy Principles. Keep what you need to diagnose and replay, mask what you do not, set a retention period and honour it, restrict who can read payloads, and know which country the logs are stored in. Useful logs and responsible logs are not in conflict, but the default settings rarely give you both.

One person holds all the knowledge and the access

Integrations built by a single developer or a departed contractor are usually replaced rather than repaired, because nobody will risk touching what they cannot see. The system map, the credentials in shared custody, the runbook for each flow and the change history should exist independently of any individual, and should be handed over as part of the work rather than reconstructed after they leave.

How Yes AI Runs Integration Support

A health check on what you already have

We review your existing connections for silent failure risk: what is monitored, what is not, where credentials sit, whether failed records are recoverable and whether anyone would notice a stoppage before finance did. You get the findings and the priority order whether or not we take over support.

Alerting designed around your operating rhythm

Severity tied to business impact, alerts routed to people rather than dashboards, and a scheduled all clear so silence is never ambiguous. Thresholds are set against your seasonal profile, so a quiet January does not page anyone and a quiet November does.

Managed on infrastructure we operate

Flows run on a managed cloud automation layer with record level logging, exception queues and replay built in from the first day rather than added after the first incident. You do not run servers or keep scripts alive, and you can see what moved and when.

Reconciliation you can hand to finance

A daily comparison of counts and values between connected systems, with the exceptions listed and explained. It is the report that ends the argument about which system is right, and it usually pays for the monitoring on its own.

From Unwatched to Supported

Five steps. Monitoring on the highest risk flow is usually live within two weeks.

Inventory the flows and the blind spots

Every connection, what it moves, how often, who owns the credential, and what would happen if it stopped this afternoon. Most businesses find one or two flows nobody knew were still running.

Rank by business impact

Money, stock and customer promises first, reporting extracts later. Monitoring effort follows consequence rather than technical interest, and the ranking is agreed with you rather than assumed.

Instrument heartbeat, volume and reconciliation

Run confirmation, volume deviation against a seasonal profile, and a daily count and value comparison per flow, with alerts routed to a named owner and a scheduled summary.

Add exception queues and tested replay

Failed records retained with their reasons and payloads, a queue someone reviews each morning, and a replay path that has been exercised in advance rather than discovered mid incident.

Runbooks, response targets and change watch

A short runbook per flow, agreed response targets by severity, and monitoring of vendor interface changes so a deprecation is handled before the deadline rather than on the morning after it.

FAQ

What does integration monitoring actually involve?

Four layers. A heartbeat that confirms each scheduled flow ran, a volume check that compares throughput against what is normal for that hour and season, a reconciliation that compares record counts and values between the two systems, and an exception queue that holds anything that failed with its reason and payload so it can be replayed. Uptime checks alone are the weakest of the four, because an integration can run flawlessly while moving nothing.

How quickly should we hear about a failure?

For anything touching orders, stock, payments or customer commitments, the same day, and ideally within the hour for a flow that runs continuously. For reporting extracts and low urgency batches, next business day is usually fine. The point is that the target is agreed and the alert reaches a person rather than a screen. If your current arrangement cannot tell you when you would find out, that is the answer: at reconciliation.

What is the difference between monitoring and support?

Monitoring tells you something is wrong. Support fixes it. A complete arrangement covers both: detection, a named owner, response targets by severity, diagnosis, the fix, replay of anything that was missed, and a note explaining what happened. Buying monitoring without support gives you a well documented outage, and buying support without monitoring means the clock only starts when someone happens to notice.

Can we monitor integrations we did not build?

Usually, yes, and it is a common starting point. Reconciliation and volume checks compare what is in each system, so they work regardless of who built the connection or what it runs on. Heartbeats and exception queues may need cooperation from whatever is running the flow, and where a connector is a closed vendor product the practical answer is often to reconcile around it and alert on the differences. That is still far better than nothing.

Does an off the shelf connector need monitoring too?

Yes. A connector from your ecommerce or accounting platform can be an excellent choice, and we will often recommend one over a custom build. What it does not give you is an independent check that the data arrived, or an alert to your team when it stops. Reconciling the two systems daily and alerting on the difference is cheap insurance regardless of what is doing the moving, and it is the control an auditor or a bookkeeper will actually value.

What should a support agreement include?

Response targets by severity, hours of cover and what happens outside them, who the named contacts are on both sides, whether vendor interface changes and version upgrades are included, how many rule changes a month are covered before extra work is quoted, where logs live and for how long, and what is explicitly excluded. Also ask what happens at the end: whether documentation, credentials and access transfer cleanly if you move to someone else.

How much should ongoing integration support cost?

It varies with the number of flows, their volume and the consequence of failure, but a useful planning figure is that running an integration over its life costs roughly twenty to forty percent of what it cost to build. Be cautious about pricing that scales per record or per order, because it charges you most in your best trading month. We quote a flat managed fee with agreed response targets, and we would rather tell you a flow does not need paid monitoring than sell you a plan for it.

Find Out What Would Happen If It Stopped Today

Book a call. We will map your existing connections, show you which failures would go unnoticed and for how long, and give you a priced monitoring and support plan. The health check is yours either way.