Integration Monitoring and Alerting: Nobody Watches Dashboards at 3 a.m.

Every integration channel in a commerce estate ships with a monitoring screen, and every estate has a story about the feed that failed for eleven days while its monitoring screen faithfully displayed the failures to nobody. Monitoring that requires a human to go look is documentation of past incidents; alerting is what prevents future ones. This guide covers the signal sources a SAP Commerce integration estate produces, the principle that catches the failures status codes miss, and a concrete alert-pipeline pattern adapted from the CX Works import-monitor material: originally built against Marketing Cloud's monitoring API, the shape transfers to any monitored surface, which is why it is worth keeping.

The Signal Sources#

Four families of built-in signal, each with a screen and, more importantly, a queryable surface:

1. Integration API monitoring (inbound and outbound request logs per Integration Object, with payloads and outcomes, in Backoffice). Queryable as data, which makes it alertable: failed inbound requests per IO per window is a FlexibleSearch away.
2. Webhook delivery monitoring: per-configuration delivery outcomes; a destination that stopped accepting is visible here first (the webhooks guide's sender-side view).
3. OutboundSync: change items and their sync status; stuck or erroring replication accumulates visibly.
4. Hot folder and import processing: per-file outcomes, plus the ImpEx dump-file contract from the ImpEx guide (a non-empty dump is a failure even when the job "finished"), plus the cronjob result states and durations from the cronjob guide.

Around them, the platform-level surfaces: application logs (patterns like repeated ImpExException, destination timeouts), Dynatrace metrics for rates and latencies, and database-derived metrics for queue-ish tables (unprocessed rows by age).

The Freshness Principle#

The most damaging integration failures produce no errors. The upstream system stops sending; the trigger got disabled; the filter script now rejects everything; the partner rotated credentials and their sender silently gave up. Error-rate alerting sees a quieter, healthier system. The fix is to alert on staleness, not just failure:

• Every integration flow gets a declared cadence ("stock deltas at least hourly", "orders to ERP within 5 minutes", "price file daily by 05:00").
• A freshness check compares last-successful-activity against that cadence: newest successful inbound request per IO, newest processed file per hot folder channel, newest completed sync per OutboundSync config, newest SUCCESS per critical cronjob.
• Staleness beyond tolerance alerts at the same severity as failure, because to the business it is the same event: the data stopped.

Pair freshness with plausibility on the flows that matter: the order feed that succeeded with zero orders on a Tuesday morning, the stock import whose row count dropped 95% against its trailing average. Cheap assertions, embarrassing failures prevented.

An Alert Pipeline That Builds Itself: The iFlow Pattern#

The CX Works source demonstrates a pattern worth generalizing: a timer-driven Cloud Integration flow (SAP Integration Suite) that polls a monitoring API, filters for trouble, and delivers notifications. Its anatomy, translated to a commerce estate:

1. Timer start event on your check cadence (the source used intervals matched to import frequency; match yours to each flow's declared cadence).
2. Query step: an OData or REST call against the monitored surface. For commerce that can be the Integration API monitoring data, a purpose-built health endpoint you expose (a tiny OCC or IO surface answering "last N flow outcomes"), or the flow's own business data ("orders created since T").
3. Condition step: route on failures found, staleness detected, or implausible counts; end quietly otherwise.
4. Formatting step: build a human-useful message: flow name, window, counts, first error text, and the runbook link. The source's mapping step (raw monitor payload to readable email) is where most homegrown alerts skimp and become ignorable noise.
5. Delivery adapter: mail for the audit trail, chat webhook for the on-call channel, both for high severity. The source used the mail adapter; the pattern is adapter-agnostic.

Why bother when Dynatrace exists? Use both, by strength: Dynatrace owns metrics-shaped signals (rates, latencies, resource anomalies, log-pattern alerts, per the observability guide); the iFlow pattern owns business-semantic checks that need queries and context (per-IO freshness against per-flow cadences, dump-file contents, cross-system reconciliation counts). If you run Integration Suite anyway for iFlows, the alerting flow costs an afternoon and lives where integration operators already work. Without Integration Suite, the identical shape implements as a scheduled function (Kyma) or a meta-cronjob inside commerce; the pattern, not the product, is the point.

Alert Design: The Difference Between Signal and Spam#

Rules that decide whether on-call trusts the system, learned across every estate the same way:

• Deduplicate and window. One failing flow produces one open alert that updates, not four hundred emails; the check that runs every five minutes alerts on transition (healthy to failing) and re-alerts on escalation, not on every poll.
• Severity means something: paging severity for customer-visible or money-path flows (orders out, payments, stock in during trading), business-hours severity for enrichment and analytics flows, ticket-only for self-healing retries that succeeded. Publish the mapping; argue about it once, not per incident.
• Every alert carries its runbook: what this flow is, who owns it, first three diagnostic steps (which usually start at the monitoring screens above), replay procedure (the webhook guide's dead-letter replay, hot folder file re-drop, OutboundSync retry). An alert without a next action trains people to ignore alerts.
• Route to owners, not to everyone. The integration inventory (side-by-side guide) names an owner per flow; alerts follow that column. Broadcast channels are where accountability goes to die.
• Test the alerting itself quarterly: break a staging flow on purpose, verify the alert arrives, is readable, and the runbook works. Alerting that has never fired is a hypothesis, not a control.

Retention and the Meta-Problem#

Monitoring data is data: inbound/outbound monitoring items, webhook delivery records, and import logs grow without bound unless the retention machinery covers them (the data maintenance guide's FlexibleSearchRetentionRule recipes apply verbatim). Size retention to your investigation horizon (30 to 90 days covers most disputes) plus your audit obligations, and remember the reconciliation jobs need enough history on both sides to compare.

The Estate Checklist#

• Inventory of integration flows with owner, cadence, severity class, and runbook link; alerts route by it
• Failure alerting on all four signal families; no monitoring screen without an alert behind it
• Freshness checks against declared cadences for every flow that matters; plausibility assertions on the money paths
• One alert pipeline pattern (iFlow, function, or meta-job) owned and reused, not re-invented per flow
• Dedupe, severity mapping, and runbook links enforced as alert hygiene
• Monitoring-data retention configured; reconciliation jobs on order and stock flows
• Quarterly fire drill proving alerts fire and runbooks answer

The maturity test is one question: when did you last discover an integration failure from a customer or a colleague instead of an alert? If the answer is within a quarter, the estate has monitoring but not alerting, and this guide is the gap between the two.