Running BAS on a Schedule: Autostart, Task Scheduler and Unattended Operation

A bot you have to start by hand automates only part of the work. Real autonomy begins when it starts itself, does the job and reports back - and you hear about it only when something went wrong.

The schedule lives outside the bot

The important decision comes before any configuration: scheduling is not the bot’s job. The right shape is a bot that performs one run and exits cleanly, while something outside decides when to launch it.

The temptation to do otherwise is understandable: add an infinite loop with an hour-long pause and leave it running. Resist it. A permanently living process accumulates memory leaks, orphaned tabs and stale state; after a day of running it does not behave the way it did in the first hour. A process that starts, works and dies begins each time from a clean slate.

Which leads to the practical step: compile the project into an application and launch it like any other program.

Windows Task Scheduler

The standard route. Create a task, point it at your compiled .exe, set the schedule. A few settings usually decide whether the whole thing flies:

• “Run whether user is logged on or not” - otherwise the task waits until you sign in.
• Start-in directory. Leave it blank and the app launches from somewhere else and cannot find the resources sitting next to it. This is the number one reason a bot “works by hand but not on schedule”.
• What happens if the previous run is still going. The default can leave you with two instances at once - for a bot with threads that means double the load and, most likely, a race for the same data.
• Run task as soon as possible after a missed start - for when the machine was asleep at the appointed hour.

Starting with the system

If the bot should run continuously rather than hourly, hanging it on system startup makes more sense: the VPS reboots after updates and the bot comes back on its own, without you.

There is a non-obvious trap here: at boot the network may not be ready yet, and the bot dies on its first request. Fix it with a couple of minutes of start delay, or a connectivity check at the top of the script.

VPS: where this should live

A home computer is a poor host for scheduled automation, not because of power but because of unpredictability: sleep mode, Windows updates, dropped internet, a machine switched off by accident.

The practical requirements for a BAS VPS are modest and driven mostly by memory: budget 150-400 MB per browser thread plus headroom for the system. One separate point - do not work on the VPS through a permanently open RDP session: it stays active, consumes resources, and a dropped connection can take processes down with it. Start the task, disconnect, come back later for the result.

Recovering after a crash

Even a solid bot will eventually fall over: the site went down, memory ran out, the network dropped. The question is not whether it happens but whether it recovers without you.

The scheduler helps more than it seems: with a frequent schedule, the next launch is the recovery mechanism. All that is needed is for the bot to handle the aftermath of the previous crash at startup - not reprocess what was already done, and clean up orphaned browser processes. “Continue where we stopped” is worth far more than “start over”, especially on long lists.

Knowing the bot actually ran

The most dangerous state for an unattended bot is the silent failure. It does not crash with an error; it just stops producing anything useful. The schedule fires, the process starts, zero results, nobody notices.

So every unattended run should leave a trace:

• A result notification. A short summary in Telegram after each run - this many processed, this many failed.
• A signal that it started at all. More useful than it sounds: the absence of a message is information too. No evening report means the task never fired.
• Statistics across runs. Not just “how much did it do” but “how much does it usually do”. A run that finished twice as fast as normal usually means an empty input list, not a speed-up.
• A log file. You can only diagnose yesterday’s failure from logs written yesterday.

The benchmark is simple: if the bot goes quiet for three days, you should find out - either from it, or from the silence.