Integration Monitoring: Detecting Sync Failures Before They Cost Revenue

The most expensive integration failure is the one nobody notices. A webhook endpoint silently stops receiving events on a Friday afternoon. By Monday morning, 200 orders have not imported, inventory is 48 hours stale across all channels, and customers are receiving "in stock" promises for products that sold out Saturday.

This scenario happens more often than anyone admits. Integration monitoring is the difference between a 30-second alert and a Monday morning crisis. Every multi-channel integration needs health checks, error classification, retry logic, and alerting designed for the specific failure modes of eCommerce data sync.

Key Takeaways

• Monitor data freshness, not just uptime — a running system that stopped receiving events looks healthy to basic health checks
• Categorize errors by severity and recoverability to route them to the right response (auto-retry vs manual fix)
• Dead letter queues prevent poison messages from blocking your entire pipeline
• Alert on business impact metrics (orders not imported, inventory drift) not just technical metrics (CPU, memory)

---

What to Monitor

Integration monitoring covers three layers: infrastructure health, data flow health, and business outcome health.

Infrastructure Health

| Metric | Check Frequency | Alert Threshold | Impact of Failure | |--------|----------------|----------------|-------------------| | API endpoint availability | Every 30 seconds | 3 consecutive failures | Cannot send or receive data | | Message queue depth | Every minute | Queue depth above 1,000 for 5 minutes | Processing backlog growing | | Worker process status | Every 30 seconds | Worker down for 1 minute | Events not being processed | | Database connection pool | Every minute | Available connections below 10% | Queries failing or queuing | | Redis connection | Every 30 seconds | Connection lost | Cache, queues, and locks failing | | Disk space | Every 5 minutes | Below 10% free | Log rotation failing, DB stalling |

Data Flow Health

| Metric | Check Frequency | Alert Threshold | Impact of Failure | |--------|----------------|----------------|-------------------| | Orders imported (per channel) | Every 15 minutes | Zero orders for 2 hours during business hours | Missing revenue and fulfillment delays | | Inventory sync age | Every 5 minutes | Last successful sync over 10 minutes ago | Stale inventory causing oversells | | Product feed status | Every hour | Feed rejected or items disapproved above 5% | Listings deactivated on marketplace | | Webhook delivery rate | Every 15 minutes | Below 95% delivery success | Events being dropped | | Transformation error rate | Every 5 minutes | Above 1% error rate | Bad data entering ERP | | Reconciliation drift | Every 6 hours | Drift above 5 units on any SKU | Inventory inaccuracy |

Business Outcome Health

| Metric | Check Frequency | Alert Threshold | Impact of Failure | |--------|----------------|----------------|-------------------| | Oversell count | Real-time | Any oversell event | Customer disappointment, marketplace penalty | | Unfulfilled orders aging | Every hour | Orders older than SLA (24/48 hours) | Late shipments, defect rate increase | | Refund processing time | Every hour | Average above 48 hours | Customer complaints, marketplace intervention | | Channel listing count | Daily | Drop of more than 5% from yesterday | Products delisted, revenue loss | | Revenue by channel vs forecast | Daily | Below 80% of daily forecast | Potential integration outage or listing issue |

---

Error Categorization

Not all errors are equal. A transient network timeout resolves itself on retry. A data validation error requires human investigation. A rate limit error needs backoff. Categorizing errors correctly determines the response.

Error Type to Resolution Strategy

| Error Type | Examples | Auto-Retry | Escalation | Resolution | |-----------|---------|-----------|-----------|-----------| | Transient network | Connection timeout, DNS failure, 502/503/504 | Yes, exponential backoff | After 5 retries | Usually resolves within minutes | | Rate limit | 429 Too Many Requests | Yes, respect Retry-After header | After 30 minutes of sustained limits | Reduce request rate, increase quota | | Authentication | 401 Unauthorized, token expired | Yes (refresh token first) | After token refresh fails | Re-authenticate, check credential rotation | | Validation | Required field missing, invalid format | No | Immediately | Fix mapping or data source | | Business logic | Duplicate order, SKU not found | No | Immediately | Investigate root cause | | API change | Unexpected response format, new required field | No | Immediately (P1) | Update mapper, deploy fix | | Quota exceeded | Monthly API call limit reached | No | Immediately (P1) | Upgrade plan or optimize API usage | | Data corruption | Garbled encoding, truncated payload | No | Immediately | Investigate source, fix transformation |

Error Enrichment

Raw errors are hard to diagnose. Enrich every error with context:

• Timestamp: When the error occurred (UTC)
• Channel: Which marketplace or system
• Operation: What was being done (import order, update inventory, list product)
• Entity: The specific order ID, SKU, or customer affected
• Request/response: The API request that failed and the response received
• Retry count: How many times this has been retried
• Correlation ID: A unique ID linking related operations across services

---

Retry Strategies

Retries handle transient failures automatically, but poorly designed retry logic makes things worse — hammering a struggling API with retries can turn a recoverable issue into an outage.

Exponential Backoff with Jitter

The standard approach: wait progressively longer between retries, with random jitter to prevent synchronized retry storms.

| Retry | Base Delay | With Jitter (example) | |-------|-----------|----------------------| | 1 | 1 second | 0.7 seconds | | 2 | 2 seconds | 1.8 seconds | | 3 | 4 seconds | 3.2 seconds | | 4 | 8 seconds | 7.5 seconds | | 5 | 16 seconds | 14.1 seconds | | Maximum | 60 seconds | 45-60 seconds |

Retry Budget

Set a maximum number of retries per error type and a maximum retry window. An order import that fails 5 times over 30 minutes should stop retrying and move to the dead letter queue for investigation. Unlimited retries waste resources and mask persistent problems.

Circuit Breaker Pattern

When a channel API returns errors consistently, a circuit breaker stops sending requests temporarily. This prevents your system from wasting resources on a down service and gives the service time to recover.

• Closed (normal): Requests flow through. Track error rate.
• Open (tripped): All requests fail immediately without calling the API. Checked periodically.
• Half-open (testing): Allow one request through to test if the service has recovered. If it succeeds, close the circuit. If it fails, reopen.

Trip the circuit breaker when the error rate exceeds 50% over a 60-second window. Test recovery every 30 seconds.

---

Dead Letter Queues

Events that fail all retries move to a dead letter queue (DLQ). The DLQ serves two purposes: it prevents poison messages from blocking the main pipeline, and it preserves failed events for investigation and manual reprocessing.

DLQ Management

• Daily review: Assign someone to review DLQ entries every business day. Most entries are data issues that can be fixed and reprocessed.
• Categorize patterns: If the same error type appears repeatedly, fix the root cause rather than reprocessing individual events.
• Retention policy: Keep DLQ entries for 30 days. After 30 days, archive to cold storage for compliance but remove from the active queue.
• Reprocessing tools: Build a tool that lets operators reprocess a single DLQ entry or a batch of entries after fixing the underlying issue.

DLQ Metrics

Track these metrics for DLQ health:

• Inflow rate: How many events enter the DLQ per hour. Spikes indicate a systematic issue.
• Aging: How long events sit in the DLQ before resolution. Aging events represent unresolved problems.
• Resolution rate: What percentage of DLQ events are successfully reprocessed vs manually resolved vs abandoned.

---

Alerting Design

Alerts must be actionable, contextual, and routed to the right person. An alert that fires 50 times a day is ignored. An alert that wakes someone up for a non-critical issue erodes trust in the system.

Alert Severity Levels

| Level | Criteria | Response Time | Notification | Examples | |-------|---------|--------------|-------------|---------| | P1 Critical | Revenue-impacting, active data loss | 15 minutes | Page on-call, phone, SMS | Order sync stopped, all channels stale | | P2 High | Degraded performance, single channel down | 1 hour | Slack channel, email | One channel not syncing, error rate spike | | P3 Medium | Anomaly detected, not yet impacting | 4 hours | Slack channel | DLQ growing, reconciliation drift above threshold | | P4 Low | Informational, potential future issue | Next business day | Dashboard | API deprecation warning, approaching quota |

Alert Fatigue Prevention

• Consolidate related alerts: 50 individual "order import failed" alerts should be consolidated into one "order import failure spike: 50 failures in 15 minutes" alert.
• Auto-resolve transient issues: If a P2 alert resolves within 5 minutes (the circuit breaker trips, the channel recovers), downgrade to P4 and log rather than escalating.
• Maintenance windows: Suppress alerts during planned maintenance on channels or your own infrastructure.
• Runbooks: Every alert should link to a runbook that explains what the alert means, likely causes, and step-by-step resolution instructions.

---

Dashboards and Visibility

A monitoring dashboard provides at-a-glance visibility into integration health for operations teams, management, and engineering.

Recommended Dashboard Panels

Overview panel: Green/yellow/red status indicator per channel. Green = syncing within SLA. Yellow = degraded (lagging or elevated errors). Red = down (no sync in threshold window).

Order flow panel: Real-time count of orders imported per channel per hour, compared to the same hour last week. A sudden drop signals a problem.

Inventory freshness panel: Time since last successful inventory sync per channel. Anything over 10 minutes during business hours is yellow; over 30 minutes is red.

Error trend panel: Error count by type over the last 24 hours. Highlights new error types and trending issues.

DLQ panel: Current DLQ depth and aging distribution. How many entries are less than 1 hour old, 1-24 hours, and over 24 hours.

Reconciliation panel: Last reconciliation results showing drift by SKU. Sorted by largest drift first.

For the broader integration architecture, see the pillar post: The Ultimate eCommerce Integration Guide.

---

SLA Monitoring

Define and track SLAs for your integration's key data flows.

| Data Flow | SLA Target | Measurement | Consequence of Miss | |----------|-----------|-------------|---------------------| | Order import | Within 5 minutes of placement | Time from marketplace order creation to ERP import | Fulfillment delay | | Inventory propagation | Within 60 seconds of change | Time from ERP stock change to all channels updated | Oversell risk | | Price update | Within 15 minutes of change | Time from ERP price change to channel update | Pricing mismatch | | Product listing | Within 24 hours of creation | Time from PIM publish to live on channel | Lost sales opportunity | | Return processing | Within 4 hours of receipt | Time from warehouse scan to refund initiation | Customer complaint |

Track SLA compliance as a percentage (target: 99.5% or higher) and review monthly. Persistent SLA misses indicate capacity or architecture issues that need investment.

For details on the inventory sync architecture that these SLAs depend on, see Real-Time Inventory Sync Architecture.

---

Frequently Asked Questions

What monitoring tools work best for eCommerce integrations?

For infrastructure monitoring, Datadog, New Relic, or Grafana + Prometheus are standard choices. For application-level monitoring (error tracking, request tracing), Sentry is excellent for Node.js/Python stacks. For queue monitoring, BullMQ has a built-in dashboard (Bull Board), and RabbitMQ has its management UI. The key is not which tool you use — it is that you monitor all three layers (infrastructure, data flow, business outcomes) consistently.

How do I monitor webhook reliability if I do not control the sender?

You cannot directly monitor whether a marketplace is sending webhooks. Instead, monitor the absence of expected events. If your Shopify store typically receives 10 order webhooks per hour and you receive zero for 2 hours, alert. This is "negative monitoring" — detecting the absence of expected activity rather than the presence of errors.

What is an acceptable error rate for integration processing?

Below 0.5% is excellent. Between 0.5% and 2% is acceptable but warrants investigation. Above 2% indicates a systematic issue — likely a mapping problem, API change, or data quality issue at the source. Track error rates per channel and per operation type to pinpoint problems quickly.

Should I build custom monitoring or use a managed service?

Start with managed services (Datadog, Sentry) for speed of implementation. Build custom dashboards for business-specific metrics (order flow, inventory freshness, SLA compliance) that generic tools do not cover out of the box. The business-layer monitoring is where you get the most value and where generic tools fall short.

How do I handle monitoring during marketplace outages?

Marketplace outages (Amazon API degradation, Shopify platform issues) are outside your control. Your monitoring should distinguish between "our system is broken" and "the marketplace is down." Check marketplace status pages programmatically (e.g., Amazon's SHD, Shopify's status page) and annotate your dashboards during external outages. Suppress alerts for channels experiencing known external issues.

---

What Is Next

Monitoring is not a feature you ship and forget. It is a practice that evolves with your integration. As you add channels, increase volume, and encounter new failure modes, your monitoring must grow to cover them. The investment pays for itself the first time a 30-second alert prevents a weekend-long outage.

Explore ECOSIRE's integration services for production-ready integration monitoring with Odoo, or contact our team to assess your current integration observability gaps.

---

Published by ECOSIRE — helping businesses scale with AI-powered solutions across Odoo ERP, Shopify eCommerce, and OpenClaw AI.