Updates only protect a PC when they actually run. Scheduling winget sounds like a one-minute job - until the task runs, does nothing, and leaves no error you can see.
Winget has no built-in scheduler. The standard approach is a small batch file plus Windows Task Scheduler - and the standard failure is running that task as the SYSTEM account, under which winget usually cannot even be found, because winget belongs to the App Installer package registered per user. This guide builds the schedule the way that actually works, explains the trap honestly, and shows the log habit that proves your updates are really happening.
The user account line is where most guides go wrong - see Fix 2 before you copy anyone's scheduled task.
C:\Setup and a file update-apps.bat in itwinget upgrade --all --silent --accept-package-agreements --accept-source-agreements >> C:\Setup\winget-log.txt 2>&1winget-log.txt - without a log, a scheduled task is a rumour, not a systemC:\Setup\update-apps.bat. Save, then right-click the task and Run it once to watch it work under the scheduler toowinget-log.txt and confirm recent runs list real upgrades, not the same error repeatedThe video schedules exactly this task and shows the log afterwards - including the failed first attempt under the wrong account.
▶️ Watch Full VideoThe classic cause is the task running as SYSTEM, where winget is not available, so the batch fails instantly. The log file shows it plainly - usually a 'not recognised' error. Change the task to run as the user account and test again.
Weekly is the sweet spot for most PCs - frequent enough for security fixes, rare enough to not disturb work. Browsers and communication apps update themselves more often anyway; this task is the safety net for everything else.
Winget can include the msstore source in upgrades, but Store apps primarily update through the Store itself. Leave the Store's own auto-update on as well - the two systems complement each other.