A checkpoint has two separate settings that people often confuse.
Its trigger decides when the checkpoint wakes up. Its conditions decide whether it actually does anything once awake. This article is about a third setting that sits alongside them: how often the checkpoint runs at all.
You will find it in the checkpoint editor, on the Trigger tab, under How often this checkpoint runs.
You can only pick one
The four options are presented as a single list of radio buttons on purpose. They are competing answers to the same question, so a checkpoint can only follow one of them. Choosing one switches the others off.
This is enforced when you save. A checkpoint that tries to combine two of them is rejected rather than saved in a state where nobody could predict what it would do.
1. Run once
The checkpoint runs one time and finishes. This is how every checkpoint behaves by default, and it is what all of your existing checkpoints do today.
If the conditions do not match when the trigger fires, nothing is sent and the checkpoint is done.
Use it for: anything that only makes sense once per load, such as asking for a POD after delivery.
2. Re-run when the trigger fires again
Normally a checkpoint that has finished stays finished. With this option, if the trigger fires again on a checkpoint that already completed, the agent starts a fresh run instead.
The important word is again. This is driven by the trigger firing a second time, not by a clock. If the trigger never fires again, this behaves exactly like Run once.
Use it for: situations that can genuinely recur on the same load, such as a load that stops tracking, starts again, then stops again.
3. Follow up once if unanswered
The checkpoint runs, and if the carrier does not answer, the agent sends one chaser after a delay you choose.
You set the delay in minutes or hours:
Minutes: 15 minimum, 1440 maximum
Hours: 1 minimum, 24 maximum
There is only ever one chaser. This is not a loop.
Use it for: a single time-sensitive ask where silence is the problem, such as confirming an ETA before an appointment.
4. Repeat daily while conditions match
After each run, the checkpoint schedules itself again at the same time the next day, and keeps going until it is told to stop.
This is the option for a genuine daily check call: "ask the driver for a status every morning at 10:00 while the load is in transit." Before this existed, the only way to get that was to build five or six near-identical checkpoints by hand.
There are exactly two ways it stops
The conditions stop matching. This is the main one, and it is what makes the option safe. If your condition is "shipment status is In transit", then the morning the load is delivered the conditions no longer match, and the loop ends there. The conditions you already wrote are the off switch.
It reaches the run limit. A backstop, in case a load never reaches a status that ends the loop.
Nothing else stops it. In particular, ordinary updates to the shipment do not interrupt or re-time a running cadence.
The run limit
Set between 1 and 10 runs, defaulting to 10. It counts total runs for that checkpoint on that load, including the first one.
Treat it as a safety net rather than a plan. If you expect a load to be in transit for three days, do not set the limit to 3 and rely on it: let the conditions end the loop, and leave the limit high enough that it never bites.
It needs a trigger with a time of day
"The same time tomorrow" only means something if the checkpoint has a time of day to repeat at. So this option is only available on:
A number of days before/after a milestone, with a time set
At a specific time
On any other trigger the option is shown but greyed out, with a note explaining why.
If you have already chosen Repeat daily and then change the trigger to one that cannot support it, the setting is cleared back to Run once in front of you. That is deliberate: it is better to see the change while you are editing than to have the checkpoint rejected when you save.
Clock changes
The cadence follows the clock time you configured, in the timezone you configured, not a fixed 24 hours. A 10:00 check call stays at 10:00 local through a daylight saving change rather than drifting to 09:00 or 11:00.
Which one should I pick?
What you want | Pick |
Ask for something once per load | Run once |
React every time a situation recurs on the same load | Re-run when the trigger fires again |
Chase one unanswered message | Follow up once if unanswered |
A daily check call for as long as a load is in transit | Repeat daily while conditions match |
What applies whichever one you pick
Conditions are always checked at the moment the checkpoint runs, never in advance. A checkpoint scheduled for tomorrow morning is not a promise that it will send anything.
The agent's quiet window still applies. A run that falls inside it is skipped.
Pausing the agent on a load still wins. Cadence does not override it.
The agent still decides what to say. Cadence controls how often the checkpoint runs, not whether the agent judges a message worth sending on any given run.
FAQs
Will this change my existing checkpoints?
No. Every checkpoint you have today is Run once, and nothing about it changes.
Can I combine repeat daily with a follow-up?
No. They are mutually exclusive, and a checkpoint that tries to use both is rejected when saved. A repeating checkpoint is already going to message again tomorrow, so a chaser on top would mean two messages about the same thing.
What happens if the conditions do not match on one particular day?
The loop ends. The conditions are the intended off switch, so a day where they do not match is treated as the load having left the situation you cared about, not as a day to skip.
What if the agent decides not to send a message one morning?
The cadence continues. A quiet morning does not end a multi-day check call.
Can I see each run separately?
Yes. Each run is recorded on its own, so you can see every occurrence of a repeating checkpoint rather than one row that keeps being overwritten.