---
title: 'Scheduled reconciliation'
description: 'Make recurring imports and cross-system checks observable and recoverable.'
category: 'Guides'
---

Use a schedule to create recurring pipeline runs. Use stages to describe the actual work. A schedule definition, an orchestration worker, and an application worker have different roles; all must be configured for automatic execution.

## Start with a bounded batch

Choose a small batch window, for example changed customer profiles since a stored checkpoint. Use three stages: read the source window, apply idempotent updates, and record the result.

Keep the cursor in your business storage. Advance it only after the target updates are confirmed. Pipeline history helps diagnose a run; it should not be the only record of a data synchronization checkpoint.

## Define the schedule

Start with a modest interval or a five-field cron expression, an explicit IANA time zone, and an overlap policy appropriate for your job. Register or update a named schedule through the SDK. Keep schedule registration in a controlled application startup or deployment path.

Follow the complete APIs in [.NET scheduling](/docs/net/schedules) or [Java scheduling](/docs/java/schedules). The Java guide includes runnable cron, interval and one-shot examples, manual triggering, history and cleanup commands. The general [schedule guide](/docs/schedules) explains catch-up, time zones, run history, and current overlap limitations.

## Keep a worker available

Automatic ticks require a recently active application worker. An online worker for the application does not prove that every handler needed by a pipeline is registered. Use readiness checks and verify the relevant handler names.

A skipped tick is not a Completed pipeline. Inspect schedule run history for the recorded reason. Handle a NoWorker result by restoring the application worker and deciding whether a controlled manual run is appropriate.

## Make the result useful to business users

Expose the batch reference, time window, number of records examined, number updated, and exceptions requiring attention. Keep individual sensitive records in systems with the appropriate access controls.

Support can distinguish “the job did not start”, “the import stopped at a stage”, and “the import finished with a business exception”. Developers can inspect detailed attempts and logs when needed.

## Test before scheduling production data

- Run the same batch twice and verify target records are not duplicated.
- Stop the application worker and inspect the recorded schedule outcome.
- Fail the target update halfway through and resume using stable record keys.
- Check time-zone and daylight-saving behavior for the exact cron expression you deploy.
- Test manual triggering independently from automatic catch-up behavior.

Back up both Pipelogiq's database and your business checkpoints. See [deployment](/docs/deployment).