Most integrations in small companies are "invisible". They work — until they don't. And you don't learn about the outage from your system, you learn about it from the customer who calls asking why their order has been stuck for three days.
This isn't a technology problem. It's the problem of there being no warning light on the dashboard. The integration between your ERP and your online shop, between Comarch Optima and the shipping system, between your CRM and your accounting software — each of them sends data quietly, with no confirmation. Until the confirmation arrives, you assume "it's probably working". And in 95% of cases you're right. But that one case in twenty can cost you a week of chaos and three angry customers.
At one of our clients — a 25-person electrical wholesaler near Poznań — stock levels failed to sync between Comarch Optima and the B2B portal for three days. The portal's API politely returned HTTP 200, but with an empty body. Customers kept placing orders for products that hadn't been in stock for weeks. Three days of complete silence, until a call from their biggest buyer asking "where are my 400 metres of YKY cable". A simple "if today's sync returned 0 records, raise an alarm" would have caught it in 15 minutes.
What can actually go wrong
Before you start monitoring, it helps to know what you're looking for. In practice integrations fail in a few repeatable ways:
- Silent API failure — the other side responds with 200 OK, but with an empty or wrong body. Your system thinks everything went through.
- Format change on the vendor's side — someone at the courier added a field to the response, your parser crashed, the task goes to an error queue nobody reads.
- Expired token / certificate / password — usually spotted a week later when someone randomly checks the logs.
- Firewall block — new IT policy, new IP addresses after a migration, forgotten whitelist.
- Full disk / full tablespace — the job runs, but there's nowhere to write the result.
- Rate limiting — the external API started returning 429, your script retries forever, the queue grows.
- Logical inconsistency — the data "goes through" but makes no sense (customer without a tax ID, order with price zero, invoice dated 1970).
Each of these outages has a different signature. Good monitoring catches all of them, not just "server is up".
Three layers of monitoring
You don't need Datadog at EUR 2k a month. You need three layers, each built in half a day.
Layer 1 — did the integration even start. Every integration job should finish with an entry like "completed at 03:17, processed 847 records". If the entry isn't there, your scheduler died, the server froze, or the job hung. The alert is simple: "if there's no success entry between 3:00 and 3:30, send an email". One line in cron, 15 minutes of work.
Layer 2 — does what came through make sense. This is where it gets interesting. An alert like "if today's sync returned 0 records, but yesterday it was 1200, raise a flag" catches most silent failures. Add the opposite one too: "if today's sync returned 10× the 30-day average, raise a flag" — that catches duplicates and infinite loops.
Layer 3 — is the data business-correct. A daily report that checks, for example, that every e-shop order from the last 24 h has a matching document in the ERP, and every ERP invoice has a fiscalised entry. A simple script comparing two databases by order ID, run at 6:00. If the mismatch list is empty — it stays quiet. If it has even one record — it emails two people.
Three layers together catch roughly 90% of the real-world outages we see. The rest is the fancy stuff — and usually not relevant for 10–50-person companies.
Alerts someone actually reads
The biggest mistake when deploying monitoring: generating alerts nobody reads after a week. Then an outage comes, the email lands in a folder with 400 others, and nobody sees it.
A few rules that save the day:
- One outage = one email a day, not a hundred. If the integration fails 50 times overnight, don't send 50 emails. One email at 7:00 saying "50 errors between 23:00 and 06:00, first at X, last at Y" is enough.
- An alert must say what's broken and what to do. "Allegro integration — no response for 2 hours, token likely expired (last time: 2026-07-12). Renew it in Allegro panel: Account → API." Not "ERROR: 401 Unauthorized".
- Alerts go to two people, not one. One person is on holiday or sick. Two people is the minimum for continuity.
- Separate channel for integration alerts. Don't dump them in the main admin inbox next to printer monitoring. Separate email, separate Teams channel, separate view.
At the electrical wholesaler mentioned above, after rolling out these rules, average time to detect an integration outage dropped from "a few days" (i.e. until the next customer complaint) to about 20 minutes. The cost? Three days of work, zero new licenses. The monitoring was built on SQL Server, a Windows cron and one Microsoft 365 inbox.
What you can't monitor
Not everything is a technical problem. Some things need a process — meaning a person who looks at a specific report once a week.
Real examples: an order comes into the ERP, but the sales rep forgets to assign it to themselves and nobody calls the customer. The system sees no failure here — the data moved correctly. Or: the bank integration pulls the statement, but 10% of payments don't match invoices automatically (because customers put nonsense in the transfer title). The system catches it, but someone has to resolve it by hand.
Don't build monitoring for things like this. Build a short, weekly review. 15 minutes every Monday: someone (ideally the same person each time) opens the "unmatched payments", "orders without an assigned rep", "invoices without shipping" reports. As long as the report is in the rotation — the problems are under control. The moment someone stops opening it, the company starts quietly losing money.
Where to start in your company
Not with buying a tool. Start with an hour, a sheet of paper, and a list of every integration you have — including the ones "everyone forgot about because your old IT guy set them up 5 years ago".
For each item on the list, answer three questions: where to where does the data flow, what happens if it fails for a week starting today, who will find out and when. Usually it turns out that for half the integrations the answer to the third question is: "the customer, in 3–5 days, by phone".
That is your priority list. You start with the one whose outage hurts the most.
If you'd like to walk through which integrations in your company are worth monitoring first, the first conversation is free and takes half an hour. We leave it with a short list of "three things to do in the first month", even if we don't end up working together.
An integration nobody knows is down has been down since Wednesday. You just won't find out until Friday — from a customer.