integration-monitoringlisted

# Integration monitoring When a third party degrades, your service degrades and your dashboards show your own errors. Monitoring integrations separately is what turns an hour of confused investigation into an immediate attribution. ## Method 1. **Measure each dependency separately.** Latency, error rate, and timeout rate per integration, so a problem is attributable at a glance (see observability). 2. **Alert on their error rate, not only on yours.** A rising provider error rate is your early warning before it becomes user-visible. 3. **Track quota consumption.** Approaching a limit is a predictable incident that monitoring can prevent (see rate-limit-handling). 4. **Watch latency percentiles, not averages.** A provider degrading at the tail affects a subset of users invisibly in the mean. 5. **Monitor webhook delivery gaps.** Absence of events looks identical to quiet, so expected-rate alerts catch silent failures (see webhook-consumption). 6. **Subscribe to their status page and changelog.** Their incident communication is a signal your monitoring cannot produce. 7. **Log correlation identifiers from both sides.** Their request id stored with yours is what makes a support conversation productive. ## Boundaries Monitoring detects and does not prevent, so it pairs with resilience (see integration-resilience). You cannot see inside a provider, only their responses to you. Status pages are often updated after customers notice.