Routing & Automation
Part of Support platform reliability
Monitoring integration delays that affect agents
Measure the age of information agents see, combine queue and delivery signals, and respond safely to stale connected data.
Monitor an integration by the age of the information an agent can use. A connector may run while an order update or customer record arrives too late for the support decision. Set an acceptable age for each critical data path, then compare the source change with what appears in the agent view.
Map the path and its clock
Record where an event begins, how it travels and where the agent sees the result. Where available, keep three times: the source change, the integration’s acceptance of the event and the update becoming visible in the support workspace. Compare the first and last using synchronised clocks, consistent time zones and a reliable record match. Without those conditions, a precise-looking delay can mislead.
An order lookup might pass through a queue into a helpdesk sidebar. If the agent sees yesterday’s fulfilment state, a successful connector heartbeat does not make the value safe to use. Decide what age requires an agent to open the authoritative source record before making a customer promise.
Use signals that identify the failing stage
| Signal | Question it helps answer | Limit |
|---|---|---|
| Source-to-agent age | How old is the displayed value? | Needs trustworthy times and a matched record. |
| Queue age and backlog | Are updates waiting to be processed? | Does not prove the displayed record is correct. |
| Failed or retried delivery | Which events met an error? | A retry may succeed or repeat an action. |
| Controlled end-to-end check | Did a known change reach the agent view? | One case cannot represent every record type. |
For an integration that uses Amazon SQS, CloudWatch exposes the approximate age of the oldest message. On standard queues, AWS notes that the oldest-age measure can exclude repeatedly failing messages; a dead-letter queue has its own age behaviour. Treat these as diagnostic signals, not an exact count of delayed customer records. Inspect the dead-letter queue and compare a source change with the agent view.
Zendesk’s webhook activity log shows invocations and failed requests. Zendesk documents retries for certain HTTP response codes and notes that duplicate invocations can occur. A successful webhook request alone does not establish that the receiving system updated the intended case. The integration owner needs an acknowledgement or reconciliation step appropriate to that system.
Turn delay into an agent action
Set the threshold from the support decision. Background context may tolerate more age than a value needed before a refund or delivery promise. When a threshold is crossed, show the last confirmed update and a clear warning where the workspace supports it. Route urgent cases to an approved manual check and keep the customer-facing owner on the case.
Give the technical alert a recipient and a response procedure: identify the affected source and period, inspect failures and backlog, decide whether records are missing or late, and reconcile after recovery. Avoid a blind replay that might repeat a customer action. Record the first known delayed event and the last confirmed catch-up point so support leads can identify cases needing review.
After a fix, verify a new event in the agent view and inspect cases from the affected interval. Clear a stale-data warning when the path is again within the agreed threshold, rather than when an error counter alone falls.
