Python script works manually but not in Task Scheduler: the Microsoft Store python stub (and a daily alive check)

My Python script ran perfectly when I started it by hand. My weekly publish job had produced nothing for 3 weeks, and I got zero error messages. On July 7 I found one problem: the scheduled task called plain python, which in the scheduler's environment resolved to the Microsoft Store stub. That fake python.exe did no work and exited. I replaced python with the full path to the real interpreter. Then I added a daily "I'm alive" message so the next silent failure can't hide for weeks.

Correction (October 17, 2026): The first version of this post said the Saturday task's result code, -196608, came from the Microsoft Store python stub. My later repair notes show that code came from escaped quotes in the task's settings. The stub problem below was real, and I fixed it, but it wasn't behind that code. Details are in the "A second cause" section.

If you only need the fix, jump to "The one-line fix" below. The rest is how I found it and what I changed so it can't happen quietly again.

By L

Contents

1. What I saw: no failure alert, and no success alert either
2. What I checked first: what the scheduler was starting
3. The cause: the scheduler found a different python
4. Reproduce it on your own PC
5. The one-line fix
6. A second cause I found later
7. Why the fix didn't make me feel better
8. The daily one-line health report
9. 5 checks you can run on your own automation today
10. Why this matters more when money is involved
11. FAQ

What I saw: no failure alert, and no success alert either

At the time, I had a weekly job that published a blog post every Saturday. (The job was scheduled to start automatically. Once I had added a phone approval button, the final publish step waited for my tap. Why I keep a human on that step is in my post on what not to automate.) One week the post wasn't there. I went through my own run logs and found nothing for 3 weeks in a row. The daily morning summary that normally lands on my phone had also skipped 3 days.

I hadn't received a single failure alert in those three weeks. That was the part that scared me. The system didn't fail to tell me about a failure. The failure never got recorded anywhere. For 3 weeks I assumed things were running, and nothing was running.

What I checked first: what the scheduler was starting

The script itself was fine. I could run it in my terminal any time and it worked. So I looked at what the scheduler was actually starting.

The cause: the scheduler found a different python

Windows ships a python command even on machines where you never installed Python. It is an App Execution Alias. Run it, and it tries to open the Microsoft Store page for Python. It does not run your script.

When you type a bare command like python, Windows walks through a list of folders (the PATH) in order and uses the first match. In my user terminal, the folder with the real Python came first, so everything worked. In the environment Task Scheduler used, the folder with the Store stub came first. The same python command was starting a different program in each environment.

A task that starts the stub runs on time, does nothing and exits quietly. My AI briefing task had the same problem.

I learned that a successful run in my terminal didn't tell me whether the scheduled task would work. Task Scheduler was using a different environment.

Reproduce it on your own PC

To check your setup, run the commands below and look at the task's settings.

1. Open Command Prompt and run:

where python

1. Read every line it prints, in order. Windows uses the first one. Then test each line directly by running it with its full path:

"C:\full\path\from\where\python.exe" --version

A working interpreter prints a version line such as Python 3.x.x. If a candidate prints no version, or opens the Microsoft Store instead, it is not a working interpreter. That is the one you don't want the scheduler to pick.

1. Open Task Scheduler, find your task, and open Properties > Actions > Edit.
2. Look at the Program/script field. If it says just python (or python.exe), the task depends on PATH order, and PATH order can differ between your terminal and the scheduler.

The one-line fix

I put the full path of the real interpreter into the task's Program/script field instead of the bare name. Take the path from the where python output that printed a real Python version in the --version test.

Before:

Program/script:  python
Add arguments:   C:\path\to\weekly_publish.py

After:

Program/script:  C:\path\to\real\Python\python.exe
Add arguments:   C:\path\to\weekly_publish.py

(The paths above are placeholders. Use the ones from your own machine.)

After that change, the next publish went through.

There is a second option: turn off the python entry under Windows Settings > Apps > App execution aliases. I prefer the absolute path. If you switch to another PC or another user account, the alias may be back on, and you fall into the same hole. A full path doesn't depend on any of that.

The same rule applies beyond Python. Any task that calls a program by bare name (node, git, a batch file) can pick up a different file depending on where it runs. I now point every scheduled task at an exact file path.

A second cause I found later

On July 18 the Saturday task failed again, right after it started. Its result code was -196608, which is the same value as 0xFFFD0000. My July 19 repair notes identify the cause: escaped quotes (\") around the script path in the task's Arguments field, so PowerShell couldn't find the script. That also explained the Saturday failure on July 4. After I registered the task again with plain quotes, a test run returned 0.

The first version of this post presented that code as the clue that led to the stub. That was wrong, so I've corrected it. The quotes story has its own post: Windows Task Scheduler said "Ready" but my task never ran.

Why the fix didn't make me feel better

Back on July 7, fixing the Python path hadn't reassured me. That time it was a fake Python. Next time it would be something else, and it would fail just as quietly.

When no message arrived, I couldn't tell whether the automation was running or had stopped. I also didn't want to open run logs by hand every day. If I have to check manually, why automate at all?

I set up the system to send me a daily report.

The daily one-line health report

I built a small watcher that checks six things at a fixed time each day and sends a one-line summary to my phone:

1. Is the server that receives jobs responding?
2. Is the worker program that processes jobs alive?
3. Are the server's always-on functions running?
4. Did today's scheduled jobs run at their scheduled time?
5. Was the run log updated within the last 48 hours?
6. Did the weekly publish job start and then never finish?

Two rules made it work:

• 30-minute rule. If a job has no run record 30 minutes after its scheduled time, the watcher treats it as a silent miss and sends an alert.
• Green line every day. Even when all 6 checks pass, it sends a green 1-line message. If the green line doesn't arrive, either the watcher died or the message failed to reach me. Both mean I go and look.

Before this happened, I hadn't paid much attention to success messages. If you only alert on failure, then the day your alert system dies with everything else, you hear nothing, and nothing looks the same as fine. If the daily success message doesn't arrive, I know I need to check.

5 checks you can run on your own automation today

Check	Question to ask	Pass condition
What runs it	Is the task registered as bare python?	Full path to the real interpreter
Success signal	Do I hear anything when it works?	1 line every day, even when all is fine
Failure signal	How fast would I know it died?	Alert if nothing ran 30 minutes after schedule
Completion	Am I trusting a "started" record as success?	Check for a "finished" record too
Freshness	Do I know when the last run was?	Inspect if silent for more than 48 hours

Start with the first 2 rows. Open Task Scheduler and confirm each task points at a real path. Then make sure something reaches you once a day when everything is normal. It doesn't need to be a big monitoring system. One line on your phone is enough, because the day that line doesn't come is the day you find out.

Why this matters more when money is involved

My failure cost me 3 weeks of blog posts. If the same thing happened to an automated purchase or an automatic transfer, 3 silent weeks would be a real financial loss. For anything that moves money, I now design "how fast will I know it stopped?" before "what does it earn?"

Since this incident, every time I build a new automation I first write down one answer: if this dies, when and how will I find out? Without that answer, I still don't know how I'll notice a failure. Since I made the daily check a habit, I haven't had another 3-week silent failure.

FAQ

Why does my script work in the terminal but not in Task Scheduler?
The scheduler runs in a different environment, and the folder search order for commands can differ. The same python can resolve to a different file, such as the Store stub. Registering the absolute path removes that difference.

What is the Python Store stub?
A placeholder executable Windows includes by default. On a PC without Python it sends you to the Store install page. When it runs, your script does not.

How do I find the real Python path?
Run where python in Command Prompt, then run each listed path with --version. Use the one that prints a Python version. I pasted that path into the task's Program/script field, and that task stopped starting the stub.

What's the simplest way to catch silent failures?
Send a message on success too. Failure-only alerts can't catch the case where the alerting piece dies with everything else.