A customer clicks Sync now, and your application reports success.
The request to the third-party CRM returned HTTP 200. The integration dashboard is green. No infrastructure alarm fired.
An hour later, the customer notices that half of yesterday’s contacts never appeared.
This is why monitoring APIs and integrations is harder than checking whether an endpoint responds.
An integration can be technically reachable while still failing the business outcome it exists to deliver. Requests can succeed slowly enough to damage a workflow. Authentication can fail for one customer while everyone else is healthy. Webhooks can stop arriving, queues can build behind a healthy API, and a provider can return successful responses containing data your application no longer handles correctly.
Good integration monitoring therefore needs to establish both whether the connection is technically healthy and whether the expected business result is still happening.
For Levelworks, this is primarily an Observable and Integrable App Health concern. An application cannot be considered reliably integrated with external systems if teams only discover broken data flows when customers report them.
Google SRE's monitoring guidance describes four “golden signals” for user-facing systems: latency, traffic, errors and saturation. They provide a useful foundation for API monitoring.
Google SRE: Monitoring Distributed Systems
Measure how long requests take, not merely whether they complete.
For APIs, useful views usually include median latency plus higher percentiles such as p95 or p99. An average can remain comfortable while a smaller but important group of users experiences much slower requests.
Where possible, separate your application's own processing time from dependency time.
AWS API Gateway, for example, exposes both overall Latency and IntegrationLatency, allowing teams to distinguish total request time from the time spent waiting for the backend integration.
AWS: API Gateway Monitoring Metrics
A growing integration latency tells a different story from your own API layer becoming slower.
Track how much work is flowing through the connection.
Depending on the integration, this might mean:
Traffic provides context for everything else. Fifty failures in a minute are very different when normal traffic is 100 requests than when it is 500,000.
Monitor error rates as well as raw counts.
Useful categories include:
Avoid collapsing everything into a single “integration errors” number. A burst of expired credentials requires a very different response from an external provider returning HTTP 500.
With a third-party integration, saturation is not necessarily CPU or memory because you do not control the provider's infrastructure.
The constrained resource may instead be:
A queue growing faster than workers can consume it is an integration-health problem even while the remote API remains perfectly available.
A common blind spot is monitoring only the APIs your application exposes.
Most modern applications also consume APIs from payment providers, identity systems, CRMs, mapping services, communications platforms and other external services.
Those are two separate monitoring surfaces.
For APIs you operate, measure whether consumers can reach them, how quickly they respond and which operations fail.
For APIs your application consumes, instrument outbound calls with information such as:
OpenTelemetry defines common conventions for HTTP client and server telemetry, including request-duration metrics and traces representing outbound HTTP calls. Standardizing this telemetry makes it much easier to compare behavior across different services and integrations.
OpenTelemetry: HTTP Semantic Conventions
Tracing becomes particularly useful during diagnosis. Instead of separately seeing that checkout became slow and that the payment API's latency increased, a distributed trace can connect the dependency call directly to the customer request that triggered it.
One of the most important rules in integration monitoring is that protocol success does not necessarily mean business success.
Google SRE explicitly includes implicit failures in its discussion of error monitoring: a service can return a successful protocol response while still returning the wrong result.
Suppose an import API returns:
{
"accepted": 0,
"rejected": 250
}
The HTTP request succeeded.
The integration did not.
Monitor application-level outcomes such as:
For many integrations, the most useful health metric sits one level above HTTP.
A provider-level average can hide the operation that actually matters.
Imagine one external API exposes a fast customer lookup, a moderately fast address search and a slow report-generation endpoint.
Thousands of fast lookups can make the provider-wide latency graph appear healthy while report generation is deteriorating badly.
Segment significant operations separately.
Integration
Operation
Useful view
Payment provider
Create payment
p50, p95, p99
CRM
Fetch changed contacts
p95, failure rate
File storage
Upload document
p95 by size band
Shipping service
Create label
p95, timeout rate
Azure API Management exposes request counts, backend duration, overall request duration and response-code dimensions that can be filtered by API and backend response behavior.
Microsoft: Monitor APIs in Azure API Management
Granularity should follow business importance rather than instrumentation convenience.
Authentication problems can affect one integration, one tenant or one customer while aggregate API availability remains healthy.
Track conditions such as:
Do not simply count these as generic 4xx errors.
If 95% of customers synchronize normally while one large account has an expired OAuth authorization, the provider is healthy but that customer's integration is effectively offline.
A useful dashboard should make that distinction visible without requiring someone to search raw logs first.
Rate limiting usually provides warning signs.
If the provider exposes quota or reset information, capture it where practical. At minimum, track:
A healthy integration should not discover its capacity ceiling only after customers begin receiving 429 Too Many Requests.
Normal traffic patterns matter too. A nightly synchronization may legitimately use much more API capacity than daytime activity, so alert thresholds should reflect expected workload rather than treating every spike as abnormal.
Webhook monitoring should not stop at:
Did our webhook endpoint receive a request?
The actual path usually looks more like:
Provider event
↓
Webhook received
↓
Validated
↓
Queued
↓
Processed
↓
Business state updated
Each meaningful transition can fail.
Useful signals therefore include:
Provider behavior also matters.
GitHub, for example, documents that failed webhook deliveries are not automatically redelivered. Teams can manually redeliver them or implement their own process for finding and replaying failed deliveries.
GitHub: Handling Failed Webhook Deliveries
For an integration where losing an event can leave systems out of sync, you therefore need to monitor not only processing failures but possible delivery gaps.
Some of the most dangerous integration failures create no obvious error.
Imagine your accounting integration normally exports 8,000 invoices overnight.
Tonight, it exports 6,200.
Every API request returns successfully. No worker crashes. No quota is breached.
The missing invoices may become visible only when you compare the states of the two systems.
That comparison is reconciliation.
Examples include:
Reconciliation is particularly valuable for billing, inventory, financial and other workflows where silent inconsistency matters more than temporary endpoint availability.
It also catches mistakes in your own logic. If a new record category is accidentally excluded from a synchronization query, infrastructure monitoring may remain completely green.
Production telemetry tells you what happened to real traffic.
Synthetic monitoring asks whether an important path can work even when no customer is currently using it.
Google Cloud describes synthetic monitors as scheduled tests that can check the availability, consistency and performance of applications and APIs while recording execution status and latency.
Google Cloud: Synthetic Monitoring
A useful integration check might:
That is far more informative than simply checking:
GET /health
It can detect authentication failures, DNS problems, routing problems and some provider-side behavioral failures before a real user encounters them.
Keep synthetic tests safe and deterministic. A check that creates production orders every five minutes is likely to create a different kind of operational problem.
[Internal Link: “Real User Monitoring vs Synthetic Monitoring: Which Does Your App Need?”]
An integration can be healthy overall while broken for one operation, region or customer segment.
Useful dimensions may include:
Customer or tenant context can also matter, but be careful about using high-cardinality identifiers as metric dimensions. Depending on the monitoring system, this can become expensive or operationally awkward.
A common pattern is to keep metrics relatively low-cardinality while putting richer context—such as tenant or request identifiers—into structured logs and traces.
You want to be able to distinguish:
system-wide failure from provider-specific failure from one customer's configuration problem.
They require very different responses.
Retries can hide deterioration.
Suppose 99.9% of integration operations eventually succeed.
That sounds healthy.
But imagine 15% of requests now require two or three attempts before succeeding. Users are waiting longer, workers are consuming more capacity and a modest provider problem could quickly turn that retry volume into a substantial backlog.
Track:
A widening gap between first-attempt success and eventual success is useful early-warning evidence.
Retries should make temporary failures survivable, not make an unhealthy integration look healthy.
Monitoring becomes counterproductive when every anomaly generates an urgent alert.
An API's p95 latency moving from 210 ms to 250 ms might be worth observing without waking anybody.
A payment provider failing 20% of checkout requests requires a different response.
Google SRE recommends alerting on conditions that require human action and centering monitoring on signals that reflect user-visible service health.
For integrations, high-urgency alerts might include:
Lower-severity conditions can create tickets or dashboard warnings instead.
[Internal Link: “How to Build an Effective Application Alerting Strategy”]
An integration dashboard should help an engineer understand the situation without opening twelve separate tools.
For each important integration, consider:
Signal
What it reveals
Request volume
Current demand
Success/error rate
Immediate reliability
p95/p99 latency
Responsiveness
Error categories
Likely failure type
Authentication errors
Credential or permission problems
Rate-limit events
Provider-capacity pressure
Retry rate
Hidden degradation
Queue depth / oldest age
Processing backlog
Webhook failures
Event-delivery health
Synthetic result
End-to-end reachability
Reconciliation gap
Business-level correctness
Not every integration needs every signal.
A low-value read-only data feed does not deserve the same monitoring investment as payments or inventory synchronization.
Monitoring depth should follow the consequence of failure.
The strongest monitoring design starts with the job the integration is supposed to perform.
If its purpose is:
Keep CRM contacts synchronized within five minutes.
then meaningful health indicators could include synchronization success rate, p95 sync lag, pending records and reconciliation mismatch.
If its purpose is:
Allow customers to complete payment.
the important signals may instead be provider availability, payment-creation latency, technical failure rate, timeouts and successful checkout completion.
This approach prevents teams from building technically impressive dashboards that never answer whether the integration is actually doing its job.
[Internal Link: “Why Third-Party Integrations Fail Over Time”]
An external integration will eventually encounter something unexpected: a provider outage, expired authorization, slower responses, missing events, quota pressure or data that does not fit an old assumption.
Monitoring cannot prevent those events.
Its job is to prevent them from remaining invisible.
For Levelworks, that is the practical intersection of Observable and Integrable App Health. Teams should be able to see whether requests are flowing, whether important operations are succeeding quickly enough, whether asynchronous processing is keeping up and whether the two systems still agree about the business state they are supposed to share.
The strongest integration monitoring therefore ends one step beyond the API response.
It follows the transaction far enough to know that the work the API was called to perform actually happened.
