Tidewell

Help / Imports & exports

Why my scheduled import ran twice

Updated 4 March · 4 minute read

Duplicate runs are almost always one of two things: a timezone shift that moved the schedule across a boundary, or a retry after a partial failure that the first attempt did not report. Telling them apart takes about a minute.

Check the run log first

Open the import, then History. Two entries with the same start minute mean a retry. Two entries roughly an hour apart mean a timezone shift — almost always around the last Sunday in March or October.

If both entries show status Completed and identical row counts, your data is fine — the second run overwrote the first with the same content. No cleanup is needed.

If it was a retry

Imports retry once when the source responds but returns an incomplete payload. The first attempt is recorded as completed because rows did arrive, which is what makes this confusing.

Set a stricter completeness check on the import so a short payload fails outright instead of half-succeeding:

{
  "schedule": "0 3 * * *",
  "minRows": 500,
  "onShortPayload": "fail"
}

If it was a timezone shift

Schedules are stored in the workspace timezone, not UTC. When clocks change, a job set for 02:30 either runs twice or not at all, depending on direction.

  1. Open the import and note the scheduled time.
  2. If it falls between 01:00 and 03:59, move it outside that window — 04:15 is a safe choice.
  3. Save. The next run uses the new time immediately; no need to disable and re-enable.

Preventing both

Make the import idempotent by setting a unique key on the source rows. With a key configured, a second run updates existing rows instead of appending, and duplicates stop mattering regardless of cause.

Was this article helpful?