A script that works when you run it from an RDP window and dies the moment you disconnect was never running correctly in the first place. Windows draws a hard line between interactive user sessions and the non-interactive session in which services and scheduled tasks execute, and every long-lived piece of automation — a queue worker, a scraper, a polling integration, a nightly export — has to be built for the second world. This guide covers that boundary and the recovery settings that keep an unattended process alive when nobody is watching.
The problems are predictable: a scheduled task that reports success while doing nothing, an app that only works while someone is signed in, a process that exits at 03:00 and stays dead until morning. Fixing them does not require a service framework or a container. Task Scheduler, a few task settings, and a log file cover most cases. If you are picking a host for this kind of workload, our comparison table lists Windows VPS providers with the RAM and CPU headroom an always-on process actually needs.
Why an interactive session is the wrong home for automation
Session 0 is the isolated session where services run. It has no desktop, no interactive window station, and no user profile loaded by default. Code that calls a GUI API, opens a browser window to scrape a page, or writes to %USERPROFILE%\Documents behaves unpredictably there or fails outright. Conversely, code launched from your RDP session inherits your profile, your mapped drives, your environment variables, and your network credentials — so it works during the test and breaks as soon as you sign out.
The practical rule is that automation must run as its own account, with an explicit working directory, an explicit log path, and no dependency on anything mapped or mounted by a user. Create a dedicated local account (or a gMSA if the machine is domain-joined), grant it only the folder permissions the job needs, and test the whole thing by signing out and confirming the process still runs. If it cannot survive a logoff, it cannot survive a reboot.
Building the scheduled task so it actually fires
In Task Scheduler, the settings that decide whether a job is reliable are buried on the General and Settings tabs, not in the trigger. On General, choose “Run whether user is logged on or not” and tick “Do not store password” only if the job needs no network access; otherwise let it store the credential. Tick “Run with highest privileges” if the script touches services. On Settings, enable “Stop the task if it runs longer than” with a sensible ceiling so a hung job cannot block the next run, and set “If the task is already running” to “Do not start a new instance” for anything that writes to a shared file.
The other common failure is the working directory. A scheduled task starts in C:\Windows\System32 unless you tell it otherwise, so a script that uses relative paths finds nothing. Always specify “Start in” on the action, or make the script resolve its own location with $PSScriptRoot. And set the trigger to “At startup” with a delay of a couple of minutes — a task that starts in the same second as the network stack comes up will fail DNS resolution and exit before anyone notices.
Restart on failure: task-level and process-level
Task Scheduler has a restart policy of its own: on the Settings tab, “If the task fails, restart every” with a retry count of three and a one-minute interval covers transient failures like a database that is not ready yet. That handles the case where the process exits with a non-zero code. It does not handle the case where the process hangs forever without exiting, which is where the “Stop the task if it runs longer than” ceiling earns its place.
For a process that must run continuously rather than on a schedule, wrap it in a supervision loop rather than hoping it never dies. A short PowerShell wrapper that starts the executable, waits, checks the exit code, writes a line to the log, and loops with a backoff is more dependable than any single task setting, and it is debuggable by reading the log. Alternatively register the application as a real service with sc.exe create and configure its recovery actions — sc failure MyAgent reset= 86400 actions= restart/60000/restart/60000/restart/60000 — so Windows itself restarts it after a crash.
Logging that tells you what happened at 3 a.m.
Task Scheduler records an exit code in its own history, but that is a summary, not a diagnosis. Have every job write its own log with a timestamp, the action it took, and the outcome, and have the wrapper append a heartbeat line on each loop so you can tell “crashed and restarted” apart from “never ran”. Redirect both stdout and stderr; PowerShell’s Start-Transcript catches most of it, and 2>&1 on an executable captures the errors that otherwise vanish.
Then make the logs findable. Query the task history from PowerShell with Get-WinEvent -LogName Microsoft-Windows-TaskScheduler/Operational -MaxEvents 50, and filter the Application log for your wrapper’s source name. Rotate the job logs — a scraper writing to one file for six months will fill a 40 GB disk — and keep only the last week. The point is that when something breaks, the first question (“did it run, and what did it say?”) has an answer without you logging in at dawn.
Surviving reboots, updates and provider maintenance
Windows Update will reboot the machine whether or not your job is mid-run. Set Active Hours, or use a maintenance window, and design the job to be idempotent: if it is interrupted halfway, the next run must be able to pick up without duplicating work. That usually means writing state (the last processed ID, the last completed date) to a small file or a database row after each unit of work, not at the end of the run.
Finally, separate “the process is running” from “the process is doing useful work”. A task that is alive but blocked on an expired API token looks healthy in Task Scheduler and is useless in practice. Add a heartbeat check — a file touched every cycle, or a timestamp the job writes to the database — and alert on its age rather than on the process state. See the full specs and pricing for each provider if you need a box with enough RAM to run the workload plus the monitoring around it; a 2 GB plan leaves very little room for both.
Long-lived automation on Windows Server is not about clever code. It is about choosing session 0 over an interactive session, configuring the task so it can survive a logoff and a reboot, making failure observable through logs and heartbeats, and testing the whole thing by signing out. Do that and the job becomes boring — which is the highest compliment unattended automation can receive.
