THE SHORT ANSWER
Monitor the last usable result at each stage, not just whether a scheduled job started. Track source age, successful processing, release age and observable destination acceptance. Every meaningful alert needs an owner, an impact description and a recovery action.
Define what fresh means for each stage
A current source file, a completed import and an accepted destination release are different states. Record timestamps separately and identify the scope they cover. One fresh supplier feed does not make the entire merchant catalog current.
Set expectations from business impact and actual delivery behavior. Stock-sensitive products may require different attention from stable descriptive content. Avoid a single green status that conceals which stage is old or unverified.
Detect failures that success counters miss
A job can exit successfully after importing an empty or truncated file. Compare counts, critical field coverage and identity changes with a meaningful baseline. Also watch processing duration and queue age so a growing backlog becomes visible before releases stop entirely.
Inspect the age of the last accepted or otherwise usable output. Repeated failed attempts should not reset the freshness clock. Where destination acceptance is not observable, state that limitation and monitor the evidence you do control.
Route alerts to a useful decision
An alert should say which source or release is affected, why it matters and what to inspect next. Separate temporary retrieval errors from persistent invalid data. Group repeated failures into one incident so the responsible person can focus on the cause.
Document who can hold publication, retry a job, correct a mapping or contact a source owner. Avoid automated retries that repeatedly publish different partial outputs. Recovery should preserve the relationship between source, candidate and delivery attempts.
Verify recovery and improve the control
After resolving the cause, run the relevant checks and inspect the resulting release. Record the recovery time and evidence. A restarted worker is not sufficient proof if the exported catalog remains stale or the destination still reports an error.
Review the incident briefly: trigger, impact, cause, fix and preventive action. Add the failure to your representative sample or monitoring rules where useful. Keep the process proportionate so a small team can maintain it consistently.
ILLUSTRATIVE WORKED EXAMPLE
Make it concrete.
Illustrative example: a daily job reports success, but the source file contains only a header. A product-count check holds the release and creates one incident. The operator retrieves the complete source, verifies the candidate and confirms the new processing result before closing the incident.
Your practical checklist
- Track freshness separately for source, processing and release.
- Keep failed attempts from resetting the freshness clock.
- Check counts and critical-field changes after successful jobs.
- Assign owners and documented recovery actions.
- Close incidents only after the usable result is verified.
Common questions
Should every temporary failure notify a human?
Use bounded retries and escalation appropriate to impact. Persistent failure and stale usable output matter more than a single recoverable attempt.
Is a successful upload the final health signal?
No. Distinguish delivery from whatever acceptance or processing evidence the destination exposes.
Sources & scope
Official references checked 29 October 2026. Examples are illustrative, not customer results. Platform requirements can change; use current destination documentation for implementation decisions.
Our editorial method & corrections ↗