It depends on where the schedule lives. A task scheduled on your device usually needs that device to be awake, signed in and online at run time. A task scheduled in the vendor's cloud runs without your machine. Ask which one you are buying, because the security and reliability trade-offs differ.
Two places a schedule can live
Local schedule. The assistant's desktop app or a background process on your computer triggers the job. It can reach local files and tools, which is useful. It also means a closed lid, a sleeping machine, a dropped VPN or a signed-out session can quietly skip the run.
Cloud schedule. A service in the vendor's environment triggers the job on its own clock. It runs whether or not your laptop exists. It cannot see your local files unless you connect something, and everything it touches must be reachable from the vendor's network.
Some products offer both. If so, ask whether the user can tell which mode a given task uses, because the same prompt behaves differently in each.
What changes between the two
| Topic | Local schedule | Cloud schedule |
|---|---|---|
| Runs when device is off | Usually no | Yes |
| Reach into local files | Yes, with the user's access | No, unless uploaded or connected |
| Credentials used | Often the signed-in user's | Stored by the service or granted by OAuth |
| Missed runs | Possible and often silent | Depends on vendor retry behavior |
| Where logs live | On the device or synced | In the vendor's service |
| Who can stop it | The device owner | An admin or the task owner in the console |
Neither column is better by default. A local schedule keeps data on the device. A cloud schedule gives reliability and central control. Pick based on what the task touches.
Questions that expose the real behavior
Ask these and write down the answers.
- If the device is asleep at the scheduled time, does the task run later, run never, or run on wake?
- If it runs on wake, does it run once or once per missed slot?
- Does the user get a notice of a skipped run?
- For cloud tasks, which credentials are stored, and how are they scoped and revoked?
- For local tasks, what can the task access beyond the project folder?
The second question is where surprises hide. A job that runs once per missed slot after a long weekend can send ten reports at once.
A practical test
Do not trust the documentation alone. Create a harmless task that appends a timestamp to a note every hour. Close the lid for a night. Check the result the next morning. Then repeat with the network off and with the user signed out. Five minutes of setup shows you what the product does, which beats what the sales deck says.
Choose by what the task touches
If the task needs local files, a local schedule fits, and you accept that it is best effort. If the task must happen reliably, such as a nightly report that others depend on, a cloud schedule with alerting on failure is the safer choice. If it touches sensitive data, check where the vendor stores it and for how long before moving it to the cloud.
Safeguard can help on the security side: its policies and gates let you set rules on what an agent may change, and the free scan at gold.safeguard.sh/scan shows your dependency risk before you schedule automated updates.
A worked example: the weekend gap
A developer schedules a task for 9 a.m. every weekday that summarizes new security advisories for the team's dependencies. On Friday she closes her laptop at 6 p.m. and opens it again on Monday at 10 a.m. Three outcomes are possible, depending on the product.
| Behavior | What the team sees Monday |
|---|---|
| Skips missed runs | Nothing for the weekend, a normal 9 a.m. run is missed, next run is Tuesday |
| Runs once on wake | One summary at 10 a.m. covering the gap |
| Runs once per missed slot | Several summaries at once |
| Runs in the cloud | A summary every weekday at 9 a.m. as planned |
None of these is wrong, but each one sets a different expectation. A team that relies on the 9 a.m. summary for a stand up needs the cloud case. A developer who just wants a convenience digest can live with a skip.
Step by step: find out for yourself
- Create a task that appends a timestamp and the device name to a note every hour.
- Leave the device on and signed in for two hours. Confirm four or five entries.
- Put the device to sleep overnight and read the note in the morning.
- Repeat with the network off, then with the user signed out of the app.
- Repeat after a restart without opening the app.
- Record which cases produced entries and which produced gaps.
You now have a table of real behavior, which is worth more than a feature page. Share it with the vendor and ask them to confirm or correct it in writing.
What to do with the results
If results show gaps and the task matters, move it to a cloud schedule or add a second signal. A cheap second signal is a note or message the task writes at the end of each run, plus a person or a separate check that raises a flag when the note is missing. This pattern, sometimes called a heartbeat, detects silent skips regardless of how the product schedules work.
Also write down who is told when a task is paused because a device was offline. If nobody, the task is best effort and should be labeled as such in your task list.
Try it yourself
Click through it at your own pace, or open it full screen. Notice that the check runs on its own clock, which is the behavior a cloud schedule gives you.
Quick check
Can I rely on a local scheduled task for something critical?
Treat it as best effort. A sleeping or offline device can skip it, so use a cloud schedule or add an alert for missed runs when others depend on the result.
Does a cloud schedule mean my data leaves my network?
Anything the task reads in the cloud is processed there. Ask the vendor what is stored, for how long, and who can access it.
Can a cloud schedule see my local files?
Not unless you upload or connect them. If a task needs local files, it will usually need a local schedule, with the trade-offs described above.
Last reviewed: 19 October 2026.
