Monitoring

Silent failure: when the iFlow doesn't error, it just stops

9 min read · updated September 2026

Every integration team monitors failed messages. It is the first dashboard anyone builds on SAP Integration Suite, and the one CPI hands you closest to ready: filter the Message Processing Log by Status eq 'FAILED', wire it to an alert, done. The trouble is that this dashboard answers a single question — what went wrong? — while the most expensive incident in a SAP landscape usually comes from a different one: what stopped happening?

An integration that fails shouts. An integration that stops makes no sound at all. There is no failed message to count, because there is no message. The error report stays empty, the dashboard stays green, and the data simply stops arriving on the other side.

The point An error-based alert only fires when an execution exists. If the execution is gone, the alert goes with it — and your monitoring reports health precisely in the scenario where you most needed a warning.

How a flow stops without erroring

The causes are mundane, and that is what makes them dangerous. None of them produces a FAILED entry in the MPL:

The artefact was undeployed. Someone pushed a new version, the runtime deployment ended in Error, and the old version went off the air. No execution, therefore no recorded failure.
The schedule changed. A Timer set to run hourly was edited — or the tenant's time zone moved during a migration — and the flow now runs at three in the morning on Sundays.
The source system stopped sending. The iFlow is triggered over HTTP and is still up, perfectly healthy, waiting. What stopped was the other side: a job in S/4HANA nobody rescheduled after planned downtime.
The source query dried up. An OData delta criterion based on lastModifiedDate started returning nothing after the source system's clock was corrected.
An expired credential on an asynchronous path. The flow fetches, receives nothing, and finishes successfully. As far as CPI is concerned it ran perfectly: it processed zero records.

That last case is the most treacherous, because the monitor shows it as a successful run. It is not an absence of logs: it is a green log lying by omission.

The dead man's switch

The classic answer to this class of problem doesn't come from software — it comes from the railways. The dead man's switch is the control the driver has to keep held down; if they let go, for any reason, the train brakes. The logic is inverted compared to an ordinary alarm: silence is the alarm.

Applied to integration, the principle reads: for every critical flow, declare the maximum acceptable interval with no successful execution. Past that, alert — whether or not any error was recorded.

The immediate objection is: what about flows that are legitimately idle? A billing iFlow that only runs at month-end would alert for 28 days straight. Which is why the interval cannot be a global number. It has to be derived from each flow's own behaviour.

Working out the acceptable silence

What works is learning the cadence before policing it. Two or three weeks of observing the MPL give a reasonable baseline, per flow and per time bucket — because almost no integration has a uniform volume across the day and the week.

In practice, store the average of successful executions per combination of day of week and hour. An employee replication flow running hourly from 6am to 10pm on weekdays produces a clear profile: 16 full buckets, 8 empty ones, Saturday and Sunday empty. The alert then asks: are we in a bucket that historically has traffic? If so, and the silence has already exceeded what that bucket expects, raise it.

This handles month-end with no manual exception: that day's bucket averages zero on 27 days of the month, and the alert never fires. A genuinely irregular flow — user-triggered events, say — will never form a trustworthy baseline, and it is honest to mark it as not monitorable by cadence rather than generate noise.

Rule of thumb Scheduled flow with a stable cadence: watch for silence. Flow triggered by an external event with no pattern: watch for errors and latency, not for absence. Treating both the same way is what produces alerts nobody reads.

The alert window matters as much as the alert

Detecting is half the work. The other half is not destroying your own detection with message volume. When a flow goes down it rarely goes down once: a connectivity outage produces dozens of failures in minutes, and one alert per occurrence turns the on-call phone into something that gets switched off.

Group by flow, within a window — thirty minutes is a good starting point. The first error alerts and opens the window; the ones that follow become a counter. When the window expires, the next alert goes out carrying how many were left behind: “+47 failures grouped since the previous alert”.

That last part is not cosmetic. Grouping without saying how much was grouped makes an outage of two hundred failures look like a single isolated one, and whoever receives it sizes the response wrongly. The alert has to tell the truth about the size of the problem, not only about its existence.

What to measure, in order

Absence of execution on a flow with a known cadence — the failure no other indicator catches.
Failed executions, grouped by flow and by time window.
Successful executions with zero volume, when the flow historically moves records. This is the green log that lies.
Runtime state of the artefact — undeployed or in deployment error counts as stopped, even with the design intact.
Certificate validity for the adapters. It is the only P1 on the list with a date in the calendar, and it still takes everyone by surprise.

Where this touches what we build

iFlowMind Monitor implements exactly this design: it learns the baseline per flow and per time bucket, alerts on silence beyond what is expected, groups bursts inside a configurable window and reports how many occurrences were grouped. When there is an error, it reads the log, the stack trace and the iFlow configuration together to propose a root cause — rather than repeating the exception message back at you.

But the design stands without us. If you have a script, a job in your observability stack or a home-made dashboard, the five measures above and the grouping window fit any implementation. The mistake worth avoiding is the first one: believing that monitoring failures is monitoring the integration.