Understanding recurring Importer schedules

How the first run is chosen

Cloud Importer anchors a recurring schedule to a local date and time in the job's timezone. An hourly schedule starts at the next whole hour. For daily, weekly, monthly, and yearly schedules, PropertyDataLabs starts with that next whole hour and then applies one full interval.

For example, suppose you create a job on July 26, 2026 at 10:23 AM:

These examples use the timezone stored with the job. The job becomes eligible to start at the scheduled time. Cloud Importer checks for due jobs every five minutes, so a run may start a few minutes later. Workload, retries, or service interruptions can cause a longer delay.

The schedule does not drift

Future runs are calculated from the original schedule anchor, not from the time the previous run finished. A daily job anchored at 11:00 AM remains an 11:00 AM job even if one run finishes at 11:17 AM.

A manual run also leaves the recurring schedule unchanged. You can run a recurring job early without moving its next automatic run.

Month-end and leap-year schedules

Cloud Importer keeps the intended calendar date when possible:

• A monthly job anchored on the 31st uses the last available day in a shorter month. It returns to the 31st when a later month has that date.
• A yearly job anchored on February 29 runs on February 28 in a non-leap year. It returns to February 29 in the next leap year.

For example, a monthly schedule anchored on January 31 runs on February 28, then March 31.

Timezones and daylight saving time

The schedule stores its own timezone. Daily, weekly, monthly, and yearly jobs keep the same local hour when daylight saving time changes, even though the corresponding UTC time may change.

When you configure a recurring job, Cloud Importer chooses a timezone in this order:

1. the timezone already stored with the job;
2. your saved account timezone;
3. the timezone detected by your browser;
4. UTC when none of the above is available.

The selected timezone is displayed during job review and on the job detail page. Changing your account timezone later does not silently move an existing schedule; edit the job when you want to change its schedule timezone.

Moving or changing your account timezone

Changing your account timezone does not update existing recurring jobs. Each job keeps the timezone stored when its schedule was created or last edited. The new account timezone becomes the default for new jobs.

For example, suppose you create ten recurring jobs in America/New_York, move to Sweden, and change your account timezone to Europe/Stockholm:

• the ten existing jobs remain scheduled in America/New_York;
• new jobs default to Europe/Stockholm;
• changing an existing job requires editing that job and selecting the new timezone.

Whether you should update the existing jobs depends on what their schedule represents:

Editing a job's timezone creates a new schedule anchor, so review its new next-run time before saving. PropertyDataLabs does not automatically change every job because that could unexpectedly move many runs and cause them to start at the wrong market time.

Delayed and missed runs

Cloud Importer does not start a burst of catch-up runs after downtime. If one or more scheduled times have passed, it skips those missed occurrences and calculates the next future occurrence from the original anchor.

This keeps recurring jobs predictable and prevents several old runs from consuming credits at once.

Changes that reset the anchor

Changing the frequency or schedule timezone creates a new anchor from the time of the change. Editing unrelated settings, such as the job name or delivery destination, preserves the existing schedule.

Archiving pauses automatic runs. Unarchiving a recurring job creates a new future anchor. Previous results remain unchanged.