n8n 을 이 PC 에 깔았을 때 켤 때마다 2분 넘게 걸렸고, 실패 알림을 만들었을 때는 끝에 이렇게 적었습니다 — n8n 자체가 꺼진 것은 n8n 안의 장치로는 못 잡는다. 그 글에서 n8n 을 껐다 켜는 4분 동안 워크플로는 돌지 않았고, 놓친 실행을 나중에 몰아서 돌리지도 않았습니다.
5~50인 회사에서 n8n 을 사무실 PC 한 대에 두고 쓰면 이 일이 조용히 일어납니다. 윈도우 업데이트로 밤에 재부팅되거나, 누가 퇴근하며 PC 를 끄거나. 다음 날 아침 그 PC 는 켜져 있는데 n8n 은 안 떠 있고, 워크플로가 멈춘 것은 하루 뒤에야 압니다. 이 글은 n8n 을 사람 손 없이 뜨게 하는 것을 윈도우에 이미 들어 있는 작업 스케줄러로 만든 기록입니다.
먼저 결론 둘. 관리자 권한 없이 걸 수 있는 것은 「이 사용자가 로그온할 때」 하나였습니다. 그리고 작업 스케줄러의 「끝」 버튼은 n8n 을 끄지 못했습니다. 둘 다 아래에 있습니다.
무엇을 만들었나
세 조각입니다.
| 무엇 | 하는 일 | |
|---|---|---|
| 1 | start-n8n.cmd |
n8n 을 창 없이 켜고, 출력을 파일에 남기고, 이미 켜져 있으면 그냥 끝냅니다 |
| 2 | 작업 스케줄러의 작업 n8n-autostart |
이 사용자가 로그온하면 1 을 부릅니다 |
| 3 | stop-n8n.cmd |
n8n 을 끕니다 (「끝」 버튼이 못 끄기 때문에 필요했습니다) |
셋 다 C:\Users\사용자\n8n-autostart\ 폴더 하나에 두었습니다. 다운로드하는 것은 없습니다. 지난 글에서 터널 도구 내려받기가 회사 보안 프로그램에 막혔던 것이 있어서, 이번에는 처음부터 윈도우에 들어 있는 것만 썼습니다.
재부팅 없이 확인하는 방법부터 정했습니다
이 PC 는 다른 작업이 돌고 있어서 재부팅할 수 없었습니다. 그래서 「로그온할 때」 트리거가 실제로 재부팅 뒤에 도는 것은 이 글에서 확인하지 못했습니다. 대신 작업 스케줄러에는 트리거와 상관없이 작업을 지금 돌리는 「실행」이 있어서, 이렇게 확인했습니다.
- 작업을 「실행」 (PowerShell 에서는
Start-ScheduledTask) http://localhost:5678/을 몇 초마다 불러 200 이 올 때까지 기다리며 시각을 적음- 작업을 「끝」 → n8n 이 정말 꺼졌는지 프로세스와 5678 포트를 확인
3번에서 이 글의 두 번째 결론이 나왔습니다.
막힌 지점 1 — schtasks 는 「Access is denied」
처음에는 명령 한 줄로 걸려고 했습니다. 윈도우에 들어 있는 schtasks 입니다.
schtasks /Create /TN "n8n-autostart" /TR "C:\Users\사용자\n8n-autostart\start-n8n.cmd" /SC ONLOGON /F
ERROR: Access is denied.
/SC ONSTART(시스템 시작 시)로 바꿔도, /RU 사용자 를 붙여도 같은 한 줄이었습니다. 이 계정은 관리자 그룹에 들어 있지만, 명령을 친 PowerShell 창을 「관리자 권한으로 실행」한 것이 아니어서 그렇습니다. 관리자 권한 창을 열면 됐을 텐데, 그러지 않았습니다. 회사 PC 에서 n8n 을 쓰는 사람이 늘 관리자 권한을 갖고 있지는 않아서, 없는 채로 어디까지 되는지 보고 싶었습니다.
같은 창에서 PowerShell 의 Register-ScheduledTask 로는 됐습니다.
$action = New-ScheduledTaskAction -Execute 'C:\Users\사용자\n8n-autostart\start-n8n.cmd' `
-WorkingDirectory 'C:\Users\사용자\n8n-autostart'
$trigger = New-ScheduledTaskTrigger -AtLogOn -User '컴퓨터이름\사용자'
$settings = New-ScheduledTaskSettingsSet -ExecutionTimeLimit ([TimeSpan]::Zero) `
-MultipleInstances IgnoreNew -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries
Register-ScheduledTask -TaskName 'n8n-autostart' -Action $action -Trigger $trigger -Settings $settings
등록된 작업의 실행 계정은 사용자, 로그온 유형은 Interactive — 작업 스케줄러 창에서 보면 「보안 옵션」의 「사용자가 로그온할 때만 실행」 입니다.
같은 방법으로 다른 조합도 걸어 봤습니다. 전부 「액세스가 거부되었습니다.」 였습니다.
| 트리거 | 보안 옵션 | 결과 |
|---|---|---|
| 로그온할 때 | 사용자가 로그온할 때만 실행 | 등록됨 |
| 시스템 시작 시 | 사용자가 로그온할 때만 실행 | 액세스가 거부되었습니다 |
| 시스템 시작 시 | 로그온 여부에 관계없이 실행 (비밀번호 저장) | 액세스가 거부되었습니다 |
| 시스템 시작 시 | 로그온 여부에 관계없이 실행 (암호를 저장하지 않음) | 액세스가 거부되었습니다 |
그래서 이 글의 설정은 PC 를 켜고 누군가 이 계정으로 로그인해야 n8n 이 뜹니다. 로그인 없이 뜨게 하려면 「사용자의 로그온 여부에 관계없이 실행」을 골라야 하고, 그 옵션은 계정 비밀번호를 작업 스케줄러에 맡기는 것입니다. 그 옵션은 고르지 않았습니다. 회사 PC 의 로그인 비밀번호를 어디에 저장하는 일이라, 그걸 할지는 PC 주인이 정할 일이지 이 글이 정할 일이 아니라고 봤습니다.
한 가지 더. 작업 스케줄러 창(taskschd.msc)은 이 계정(관리자 그룹)에서 관리자 권한으로 떴습니다. 창에서 만들었으면 위 표의 거부가 안 났을 수 있습니다. 창에서는 되는데 명령줄에서는 안 되는 이유가 이것이라, 어느 쪽으로 만들었는지 적어 두는 편이 좋습니다.
막힌 지점 2 — 처음 실행은 「1」 로 끝났고, 기록은 꺼져 있었습니다
작업을 「실행」했더니 2초 만에 상태가 「준비」로 돌아왔고, 마지막 실행 결과가 1 이었습니다. 로그 파일은 만들어지지도 않았습니다.
왜인지 보려고 작업 스케줄러의 「기록」 탭을 열었는데, 탭 이름이 「기록(사용 안 함)」 입니다. 작업 기록은 기본으로 꺼져 있습니다. 오른쪽 「작업」 칸에 「모든 작업 기록 사용」이 있는데, 관리자 권한이 필요한 일로 알고 있어서 이 글에서는 누르지 않았습니다. 그래서 스케줄러 쪽에서는 아무것도 볼 수 없었습니다.
창이 안 뜨는 백그라운드 실행에서 볼 수 있는 것은 스크립트가 스스로 남긴 파일뿐입니다. 그런데 그 파일이 없으니, 스크립트가 첫 줄도 못 간 것입니다. 같은 파일을 명령 창에서 직접 돌려 보니 이렇게 나왔습니다.
'\nvm4w\nodejs' is not recognized as an internal or external command,
operable program or batch file.
'LOG' is not recognized as an internal or external command,
operable program or batch file.
set "PATH=C:\nvm4w\nodejs;%PATH%" 라고 적은 줄이 \nvm4w\nodejs 부터 명령으로 읽힌 것입니다. 원인은 줄바꿈이었습니다. 이 .cmd 파일을 만든 도구가 줄 끝을 LF 하나로 저장했고, cmd.exe 는 CRLF 가 아닌 배치 파일을 줄 중간에서 끊어 읽었습니다. 메모장에서 저장하면 나지 않는 문제인데, 다른 편집기나 스크립트로 파일을 만들면 납니다. CRLF 로 다시 저장하니 그대로 돌았습니다.
이 일에 15분이 갔습니다. 마지막 실행 결과 「1」 이 전부였고, 나머지는 스크립트를 스케줄러 밖에서 돌려 봐야 알 수 있었습니다. 처음 걸 때는 스크립트를 먼저 명령 창에서 한 번 돌려 보고 스케줄러에 거는 것이 순서입니다.
스케줄러가 주는 환경은 내 창과 다릅니다
스크립트를 고치기 전에, 스케줄러가 어떤 환경으로 부르는지부터 봤습니다. USERNAME·USERPROFILE·현재 폴더·where node·PATH 를 파일에 적는 한 줄짜리 작업을 만들어 돌렸습니다.
USER=사용자
PROFILE=C:\Users\사용자
CD=C:\Windows\System32
C:\nvm4w\nodejs\node.exe
C:\nvm4w\nodejs\npx.cmd
PATH=...;C:\Program Files\Git\cmd;%NVM_HOME%;%NVM_SYMLINK%;C:\Users\사용자\AppData\...;C:\nvm4w\nodejs;...
두 가지가 눈에 띄었습니다.
현재 폴더가 C:\Windows\System32 입니다. n8n 은 데이터를 %USERPROFILE%\.n8n 에 두므로 여기서는 문제가 안 되지만, 상대 경로로 무언가를 읽는 스크립트라면 여기서 깨집니다. 작업의 「시작 위치」를 적거나 스크립트 안에서 cd /d 를 하는 편이 안전합니다.
PATH 에 %NVM_HOME%;%NVM_SYMLINK% 가 글자 그대로 들어 있습니다. 제 창에서는 이 자리가 C:\Users\사용자\AppData\Local\nvm;C:\nvm4w\nodejs 로 풀려 있는데, 스케줄러가 준 PATH 에서는 안 풀렸습니다. 시스템 PATH 안에 다른 변수를 넣어 둔 항목이 그렇게 옵니다. 이 PC 에서는 사용자 PATH 뒤쪽에 같은 폴더가 한 번 더 있어서 node 를 찾긴 했는데, 운이 좋았던 것입니다. 그래서 스크립트에는 PATH 에 기대지 않고 node.exe 의 전체 경로를 적었습니다. where node 로 나온 그 경로입니다.
첫 실측 — 143초, 그리고 npx 를 뺐더니 69초
고친 스크립트(그때는 아직 npx --yes n8n start 를 부르는 것)로 작업을 「실행」하고 5678 포트를 두드렸습니다.
| 경과 | 응답 |
|---|---|
| +30초 ~ +95초 | 연결 없음 (시간 초과) |
| +106초 | 404 |
| +119초 · +133초 | 연결 없음 |
| +143초 | 200 |
143초. 설치 글의 130초·141초, 알림 글의 167초·239초와 같은 자리입니다. 중간에 404 가 한 번 지나갑니다 — 서버는 열렸는데 화면이 아직 준비되기 전이라, 「200 이 올 때까지」로 기다려야지 「연결이 될 때까지」로 기다리면 너무 일찍 열립니다.
설치 글에서 이 2분의 원인을 npx 로 짚고 확인은 못 했었습니다. 이번에 확인할 수 있는 자리가 생겼습니다. npx 는 n8n 을 %LOCALAPPDATA%\npm-cache\_npx\xxxx\node_modules\n8n\ 에 내려받아 두고 있었고, 그 안의 bin\n8n 을 node.exe 로 직접 부르면 npx 를 건너뜁니다.
"C:\nvm4w\nodejs\node.exe" "%LOCALAPPDATA%\npm-cache\_npx\xxxx\node_modules\n8n\bin\n8n" start
이걸로 작업을 다시 돌렸습니다.
| 회차 | 부른 방법 | 200 까지 |
|---|---|---|
| 1 | npx --yes n8n start |
143초 |
| 2 | node.exe 로 직접 |
69초 |
| 3 | node.exe 로 직접 (2회차 2분 뒤) |
21초 이하 (첫 확인이 21초였고 이미 200) |
세 번뿐이고, 2·3회차는 몇 분 사이에 연달아 돌린 것이라 디스크 캐시가 따뜻했을 것입니다. 재부팅 직후에 21초가 나온다고는 못 합니다. 다만 같은 PC 에서 npx 를 빼는 것만으로 143초가 69초가 된 것은 이 1회로도 분명했습니다. 설치 글에서 「npx 로 쓰면 켤 때마다 2분」이라고 적었던 것의 나머지 절반입니다.
_npx\xxxx 폴더는 npx 의 캐시라 npx 가 지우거나 바꿀 수 있습니다. 설치 글에서 9분 넘게 끝나지 않아 접었던 npm i -g n8n 이 되면 그쪽 경로가 더 안전할 텐데, 이 글에서도 그건 하지 않았습니다.
막힌 지점 3 — 「끝」 을 눌러도 n8n 은 살아 있습니다
이 글의 두 번째 결론입니다. 작업이 「실행 중」인 상태에서 「끝」(Stop-ScheduledTask)을 눌렀습니다. 상태는 바로 「준비」로 돌아갔습니다. 그런데 프로세스를 보니 이렇습니다.
누르기 전 누른 뒤
cmd.exe (start-n8n.cmd) (없음)
└ node.exe (npx) node.exe (npx) ← 살아 있음
└ cmd.exe cmd.exe ← 살아 있음
└ node.exe (n8n) node.exe (n8n) ← 살아 있음, 5678 응답 200
└ node.exe (실행기) node.exe (실행기) ← 살아 있음
스케줄러는 자기가 띄운 첫 프로세스(cmd.exe) 하나만 끝냈습니다. 그 아래 넷은 부모를 잃은 채 그대로 돌고, localhost:5678 은 200 을 줍니다. 「설정」 탭의 「요청할 때 실행 중인 작업이 끝나지 않으면 강제로 작업 중지」가 켜져 있는 채였는데도 그렇습니다. 작업 목록에는 「준비」라고 나오니, 화면만 보면 n8n 이 꺼진 줄 압니다.
node.exe 를 작업의 동작으로 직접 걸었을 때(2회차)는 달랐습니다. 「끝」을 누르니 n8n 과 실행기가 같이 사라지고 5678 은 닫혔습니다. 스케줄러가 끝내는 프로세스가 n8n 자신이었기 때문입니다. 대신 이 방식은 n8n 의 출력이 어디에도 안 남습니다. 창이 없으니 화면에도 없고, 파일로 보내 줄 .cmd 도 없습니다.
| 작업의 동작 | 「끝」 | 로그 |
|---|---|---|
start-n8n.cmd (감싸기) |
cmd.exe 만 죽고 n8n 은 남음 |
n8n.log 에 남음 |
node.exe … start (직접) |
n8n 까지 꺼짐 | 없음 |
로그를 택했습니다. 켜지지 않았을 때 볼 것이 없으면 위의 「1」 처럼 됩니다. 대신 끄는 파일을 따로 만들었습니다.
@echo off
rem stop-n8n.cmd - 5678 포트를 듣는 프로세스를 자식까지 함께 끝냅니다
for /f "tokens=5" %%p in ('netstat -ano ^| findstr /R /C:":5678 .*LISTENING"') do (
taskkill /PID %%p /T /F
goto :done
)
echo 5678 포트를 듣는 프로세스가 없습니다 - n8n 은 꺼져 있습니다
:done
taskkill /T 가 자식까지 끝냅니다. 돌리면 이렇게 나오고, 그 뒤 5678 은 닫혔습니다.
SUCCESS: The process with PID 27508 (child process of PID 31916) has been terminated.
SUCCESS: The process with PID 31916 (child process of PID 32332) has been terminated.
SUCCESS: The process with PID 32332 (child process of PID 34404) has been terminated.
SUCCESS: The process with PID 34404 (child process of PID 34112) has been terminated.
이미 켜져 있을 때
「끝」이 n8n 을 못 끈다는 것은, 작업은 「준비」인데 n8n 은 켜져 있는 상태가 생긴다는 뜻입니다. 그 상태에서 작업이 다시 돌면(다음 로그온, 또는 누가 「실행」을 누름) n8n 이 둘이 됩니다. 두 번째는 5678 을 못 잡고 죽겠지만, 그 전에 같은 데이터베이스를 두 프로세스가 여는 순간이 있습니다.
그래서 스크립트 첫머리에서 5678 포트가 열려 있으면 그냥 끝냅니다.
netstat -ano | findstr /R /C:":5678 .*LISTENING" >nul
if %errorlevel%==0 (
echo [%date% %time%] 5678 포트가 이미 열려 있음 - 중복 실행하지 않고 끝냅니다 >> "%SLOG%"
exit /b 0
)
위의 「끝」 실험 직후 — n8n 은 살아 있고 작업은 「준비」 — 에 작업을 「실행」했습니다. 기록입니다.
[2026-09-16 2:48:19.14] 시작 (USER=사용자)
[2026-09-16 2:48:19.20] 5678 포트가 이미 열려 있음 - 중복 실행하지 않고 끝냅니다
0.06초 만에 끝났고 마지막 실행 결과는 0, n8n 은 하나 그대로였습니다.
작업 자체가 「실행 중」일 때 다시 「실행」하는 경우는 스케줄러가 막습니다. 「설정」 탭의 「작업이 이미 실행 중이면 다음 규칙 적용: 새 인스턴스 실행 안 함」입니다. 그런데 이때 남는 기록이 이렇습니다.
마지막 실행 시간 2026-09-16 오전 2:32:43
마지막 실행 결과 운영자 또는 관리자가 요청을 거부했습니다. (0x800710E0)
「거부」라는 말이 무섭게 들리지만 실제로는 「이미 돌고 있어서 새로 안 띄웠다」는 뜻이고, 정작 돌고 있는 n8n 은 멀쩡합니다. 그리고 「마지막 실행 시간」이 그 거부된 시각으로 바뀝니다. 아무것도 안 돌았는데 시각이 갱신되니, 이 칸으로 「n8n 이 언제 켜졌나」를 읽으면 틀립니다. 켜진 시각은 스크립트가 남긴 start.log 가 맞습니다.
로그 파일이 잠깁니다
중복 실행을 시험하다가 하나 더 걸렸습니다. n8n 이 도는 동안 스크립트를 직접 한 번 더 돌렸더니 이렇게 네 줄이 나왔습니다.
다른 프로세스가 파일을 사용 중이기 때문에 프로세스가 액세스 할 수 없습니다.
첫 버전은 스크립트의 기록과 n8n 의 출력을 한 파일(n8n.log)에 >> 로 붙이고 있었습니다. n8n 이 도는 동안 그 파일은 n8n 이 잡고 있어서, 두 번째 스크립트는 「이미 켜져 있음」이라는 한 줄조차 못 적었습니다. 스크립트의 기록은 start.log, n8n 의 출력은 n8n.log 로 나눴습니다. n8n.log 가 열려 있다는 것 자체가 「지금 n8n 이 돌고 있다」는 표시가 됩니다.
사흘 뒤에 꺼지는 설정
작업 스케줄러로 만든 작업은 「설정」 탭에 「다음 시간 이상 작업이 실행되면 중지: 3 일」 이 기본으로 켜져 있습니다. schtasks 로 만든 시험용 작업을 조회하니 Stop Task If Runs X Hours and X Mins: 72:00:00 이었습니다. 몇 분 도는 작업을 위한 기본값인데, n8n 은 계속 떠 있어야 하는 것이라 이 값이 그대로면 사흘째에 스케줄러가 끄려 듭니다. 위에서 본 대로 감싼 .cmd 라면 cmd.exe 만 죽고 n8n 은 남겠지만, 직접 걸었다면 n8n 이 꺼집니다. 등록할 때 -ExecutionTimeLimit ([TimeSpan]::Zero) 로 껐고, 창에서는 이 체크가 풀린 것으로 보입니다.
사흘을 기다려 실제로 꺼지는 것을 본 것은 아닙니다. 설정이 그렇다는 것까지입니다.
완성된 것
start-n8n.cmd 의 마지막 모습입니다. 메모장에 붙여 넣고 node.exe 경로와 _npx\xxxx 폴더 이름을 자기 PC 것으로 바꾸면 됩니다.
@echo off
rem n8n 자동 시작 - 작업 스케줄러(로그온할 때)가 부르는 파일
rem 창 없이 돌므로 화면에는 아무것도 안 보입니다. 이 파일의 기록은 start.log, n8n 의 출력은 n8n.log 로 갑니다.
set "HERE=%~dp0"
set "SLOG=%HERE%start.log"
set "NLOG=%HERE%n8n.log"
rem 1) node 위치와 n8n 위치를 직접 적습니다 (npx 를 거치지 않습니다)
set "NODE=C:\nvm4w\nodejs\node.exe"
set "N8N=%LOCALAPPDATA%\npm-cache\_npx\xxxx\node_modules\n8n\bin\n8n"
echo [%date% %time%] 시작 (USER=%USERNAME%) >> "%SLOG%"
rem 2) 이미 켜져 있으면(5678 포트 LISTENING) 중복 실행하지 않습니다
netstat -ano | findstr /R /C:":5678 .*LISTENING" >nul
if %errorlevel%==0 (
echo [%date% %time%] 5678 포트가 이미 열려 있음 - 중복 실행하지 않고 끝냅니다 >> "%SLOG%"
exit /b 0
)
rem 3) 사용자 폴더로 이동해 n8n 을 켭니다 (.n8n 폴더는 USERPROFILE 아래)
cd /d "%USERPROFILE%"
echo [%date% %time%] n8n 기동 >> "%SLOG%"
echo ===== [%date% %time%] n8n start ===== >> "%NLOG%"
"%NODE%" "%N8N%" start >> "%NLOG%" 2>&1
echo [%date% %time%] n8n 종료 (exit %errorlevel%) >> "%SLOG%"
작업을 「실행」한 뒤 n8n.log 의 끝은 이렇습니다. 설치 글에서 본 파이썬 줄이 이번에도 있고, 이번에도 무시해도 됩니다.
===== [2026-09-16 2:47:51.29] n8n start =====
Initializing n8n process
n8n ready on ::, port 5678
n8n Task Broker ready on 127.0.0.1, port 5679
Failed to start Python task runner in internal mode. because Python 3 is missing from this system. ...
Registered runner "JS Task Runner" (xxxx)
Version: 2.8.4
...
Editor is now accessible via:
http://localhost:5678
이 방법으로 쓸 때 걸리는 것
로그인이 필요합니다. PC 가 켜지는 것으로는 안 되고, 이 계정으로 로그인해야 뜹니다. 로그인 없이 뜨게 하려면 「사용자의 로그온 여부에 관계없이 실행」과 계정 비밀번호가 필요하고, 그건 이 글에서 하지 않았습니다.
재부팅 뒤에 실제로 도는 것은 확인하지 못했습니다. 위에 적은 대로 이 PC 를 재부팅할 수 없어서, 「실행」 버튼으로 같은 스크립트를 세 번 돌린 것이 이 글의 실측입니다. 트리거가 로그온에서 실제로 걸리는지는 재부팅 한 번이면 알 수 있고, 그때 볼 곳은 start.log 의 첫 줄입니다.
「끝」 으로 끄지 마십시오. stop-n8n.cmd 입니다. 「끝」을 누르면 n8n 은 살고 작업만 「준비」가 되어, 화면과 실제가 어긋납니다.
잠자기·절전은 보지 않았습니다. 로그온 트리거는 잠자기에서 깨어날 때는 걸리지 않을 것이고, 그때 n8n 은 잠들기 전 상태 그대로일 텐데, 확인한 것은 아닙니다.
n8n 이 죽었을 때 다시 켜 주지는 않습니다. 이 설정은 「로그온할 때 한 번」입니다. n8n 이 도중에 죽으면 다음 로그온까지 꺼져 있습니다. 몇 분마다 5678 을 두드려 안 열려 있으면 켜는 작업을 하나 더 거는 방법이 있는데, 그건 「분 단위 반복」 트리거라 이 글의 범위 밖입니다. 스크립트의 「이미 켜져 있으면 끝」이 그때를 위해 있는 것이기도 합니다.
요약
schtasks /Create … /SC ONLOGON |
관리자 권한 없는 창에서는 Access is denied |
| 관리자 권한 없이 되는 조합 | 「로그온할 때」 + 「사용자가 로그온할 때만 실행」 하나 |
| 「로그온 여부에 관계없이 실행」 | 계정 비밀번호를 맡기는 옵션. 고르지 않았습니다 |
| 마지막 실행 결과 「1」, 로그 없음 | .cmd 의 줄 끝이 LF. CRLF 로 저장. 스케줄러에 걸기 전에 명령 창에서 한 번 |
| 「기록(사용 안 함)」 | 작업 기록은 기본 꺼짐. 볼 것은 스크립트가 남긴 파일뿐 |
| 스케줄러의 환경 | 현재 폴더 C:\Windows\System32, PATH 에 %NVM_HOME% 이 글자 그대로. node.exe 전체 경로를 적으십시오 |
| 200 까지 | npx 143초 → node 직접 69초 (각 1회) |
| 404 | 200 전에 한 번 지나갑니다. 「200 이 올 때까지」로 기다리십시오 |
| 「끝」 버튼 | 감싼 .cmd 만 죽고 n8n 은 남습니다. stop-n8n.cmd(taskkill /T)로 끄십시오 |
| 이미 켜져 있을 때 | 스크립트가 5678 을 보고 0.06초에 끝냄. 스케줄러 쪽 거부는 0x800710E0 이고 마지막 실행 시간이 갱신됩니다 |
| 로그 파일 | n8n 이 잡고 있는 파일에 다른 스크립트가 못 씁니다. start.log 와 n8n.log 로 분리 |
| 「3 일」 | 「다음 시간 이상 작업이 실행되면 중지」 기본값. 끄십시오 |
| 못 한 것 | 재부팅 후 실제 기동 · 로그인 없는 기동 · 잠자기 · 죽었을 때 재기동 |
노드도 워크플로도 없는 글이었는데, 시간이 간 곳은 이번에도 n8n 이 아니었습니다. 줄 끝 문자 하나와, 「끝」이 무엇을 끝내는가였습니다.
참고
– Microsoft Learn — 작업 스케줄러 (Task Scheduler): 보안 옵션과 작업 설정 (Task Security Context · Task Settings)
– Microsoft Learn — schtasks · PowerShell ScheduledTasks 모듈 (Register-ScheduledTask, New-ScheduledTaskSettingsSet)
– n8n 공식 문서 — 명령줄 (CLI commands) · 설치 (npm)