---
title: "Understanding recurring Importer schedules"
description: "Learn how Cloud Importer calculates hourly, daily, weekly, monthly, and yearly runs."
canonical: "https://www.propertydatalabs.com/docs/web/cloud/recurring-schedules"
---

# 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**:

| Frequency | First scheduled run       |
| --------- | ------------------------- |
| Hourly    | July 26 at 11:00 AM       |
| Daily     | July 27 at 11:00 AM       |
| Weekly    | August 2 at 11:00 AM      |
| Monthly   | August 26 at 11:00 AM     |
| Yearly    | July 26, 2027 at 11:00 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.

**Choose the timezone where the work matters**

  If you collect data for a market in another region, choose that market's timezone instead of your
  current location. The schedule then remains tied to the market when you travel.

## 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:

| You want the jobs to follow                    | Recommended action                                 |
| ---------------------------------------------- | -------------------------------------------------- |
| The original property market or business hours | Keep the existing job timezone                     |
| Your current local time after a permanent move | Edit each affected job and select the new timezone |
| Your location during a short trip              | Keep the existing job timezone                     |

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.