Start with the source of truth for the integration and your team's expected sync cadence or freshness objective. Record timestamps and operational status before changing anything. Treat an unreadable or missing signal as unknown, not as proof that data is current.
CONFIRM THE SIGNAL
Confirm sync status and age
Separate when the check ran from when the source says data last synced. Compare both with the integration's expected cadence and service objective.
Record the latest check time and result.
Capture when the freshness check ran and whether it reported fresh, stale, unreadable, or not checked. A recent check can still report an old source timestamp.
Find the source-reported last-sync time and status.
Compare the last successful sync timestamp with the current time. Note the source status and the time zone used; do not substitute the check time for the sync time.
Compare the age with the expected cadence.
Use the source's normal interval and your team's freshness objective to decide whether the delay is actionable. In a configured Mendrook freshness check, a recognized timestamp more than 15 minutes old is classified as stale; recognized delayed or failed source statuses are stale as well.
Mark missing or unreadable metadata as unknown.
If the source does not expose a usable status or sync timestamp, confirm the endpoint and metadata mapping with its owner. Do not label the integration fresh until there is evidence for it.
INVESTIGATE THE CONNECTION
Find where the sync stopped
Keep the investigation scoped to the affected integration and its data path. A reachable endpoint and a current data export are separate signals.
Identify the source, destination, and affected workflow.
Confirm which integration is behind, which downstream workflow depends on it, when it last completed successfully, and which operational owner can inspect each side.
Review the integration's operational evidence.
Check sync-job status, queue or backlog depth, retry history, checkpoints, and approved application logs. Look for the first timestamp where progress stopped and whether the source or destination reports an error.
Check recent changes and upstream conditions.
Ask the integration owner to review deployments, credential or permission changes, schema changes, rate limits, scheduled maintenance, and provider incident notices that align with the delay.
Separate data movement from endpoint reachability.
If the status endpoint responds but its sync timestamp is old, continue with the sync job, queue, and source-to-destination path. If the endpoint itself fails, use the separate API reachability guide for connection diagnostics.
COORDINATE A SAFE RECOVERY
Agree on recovery before replaying work
Bring the source and destination owners together, follow the approved runbook, and understand the effect of a retry before triggering one.
Assign an incident lead and the integration owners.
Record who is coordinating, who can change the source or destination, which workflow is affected, and where the team will track decisions and timestamps.
Choose the team's reviewed recovery procedure.
Confirm whether to restore the dependency, resume from a checkpoint, retry a bounded batch, or use another runbook step. Coordinate with the provider or system owner when their action is required.
Check replay safety and data ordering.
Before a backfill or replay, verify idempotency, duplicate handling, ordering, checkpoint behavior, and expected load. Do not force a broad replay when those effects are unknown.
Make the change, then record what was done.
Use authorized team tooling and the approved change path. Note the action, owner, start time, affected range, and any remaining backlog so the next operator can follow the recovery.
VERIFY THE RESULT
Verify freshness after recovery
Do not close the incident only because a retry completed or an endpoint answered. Confirm that the source signal and the expected sync progress have advanced.
Run or review a new freshness check.
Confirm the check happened after the recovery action and reports a readable source status and last-sync timestamp. Compare the timestamp with the current time and expected cadence.
Confirm progress at the destination using approved checks.
Use system-approved counts, sequence markers, checkpoints, or other non-conversation operational checks to verify that the intended range arrived and the backlog is moving down.
Watch the next expected sync interval.
Check that freshness remains within the team's objective on the next scheduled cycle. Reopen the investigation if the timestamp stops advancing or a stale or unreadable status returns.
Close with a concise operational record.
Record the confirmed cause if known, recovery steps, verification timestamps, remaining follow-up, and the owner. Keep customer-conversation content out of incident notes.
DATA BOUNDARY
Keep the investigation on operational metadata.
This guidance concerns integration identity, sync status, timestamps, and other operational metadata. Mendrook freshness checks use recognized status and sync-time metadata from the configured source; they do not imply that Mendrook reads call recordings, transcripts, or customer-conversation content. Keep those materials out of health endpoints and incident notes.