The next run is skipped only when the previous run's deployment is still in the Active state at the moment the next execution is due, per our cron docs. When runs overlap without a skip, it means the prior deployment is no longer marked Active (its process exited or the deployment completed) even though work is still in flight, so the scheduler sees nothing running and starts the next one.

Deployment is in Active state at the moment the next execution is due

You're correct, and this isn't something in your setup. Our docs describe the next run being skipped while a previous execution is still running, but that skip isn't currently happening. When a previous run is still in progress at the next scheduled time, we start the new run anyway instead of skipping it, so the runs overlap. What you're seeing matches that gap on our side, not your cron configuration. For now, the only reliable way to prevent overlap is to guard against concurrent runs inside the job itself (for example, a lock or an "already running" check) until the skip behavior matches what the docs describe.