n8n Schedule Trigger Not Firing: 스케줄 트리거가 예정대로 실행되지 않을 때 체크할 4가지

n8n 스케줄 트리거, 왜 조용히 실패하고 있을까요?

자동화의 핵심은 ‘정시성’입니다. 새벽 2시에 실행되어야 할 데이터 백업이, 오전 9시에 실행되어야 할 일일 보고서 발송이 예정된 시간에 실행되지 않아 업무에 차질을 빚은 경험이 있으실 것입니다. n8n(엔에잇엔)의 스케줄 트리거(Schedule Trigger)는 크론(cron) 표현식을 기반으로 동작하므로, 설정상의 작은 오류나 환경 변수 불일치가 발생하면 별도의 에러 로그 없이 조용히 무시되기 쉽습니다. 서버는 정상인데 로그에는 오류가 없는데 트리거만 반응하지 않는 난감한 상황을 해결하기 위해 오늘은 n8n 스케줄 트리거가 침묵하는 4가지 핵심 원인과 검증 방법을 단계별로 살펴보겠습니다.

원인 1: 시간대(Timezone) 불일치 – 가장 흔한 함정

n8n은 기본적으로 UTC(협정 세계시)를 기준으로 작동합니다. 만약 한국 시간(KST, UTC+9)으로 오전 9시에 실행되길 원한다면, 크론 표현식은 서버 시간이 아닌 n8n 설정의 기본 타임존을 기준으로 해석됩니다. 문제는 대부분의 VPS(클라우드 서버) 환경에서 서버 로컬 타임이 KST로 설정되어 있더라도, n8n은 독립적인 타임존 설정을 가지기 때문에 두 기준이 서로 달라질 수 있다는 점입니다.

해결 방법: 강제로 타임존 고정하기

워크플로우 우측 상단의 Settings 탭에서 Timezone 필드를 ‘Asia/Seoul’로 명시하면 서버의 로컬 시간과 무관하게 n8n 자체가 한국 시간을 기준으로 스케줄러를 작동시킵니다. Docker로 실행 중이라면 환경변수 GENERIC_TIMEZONE=Asia/Seoul과 TZ=Asia/Seoul을 함께 지정해 컨테이너와 n8n의 시간대를 일치시키는 것이 좋습니다. 변경 후에는 워크플로우를 저장하고 잠시 비활성화한 뒤 다시 활성화해야 변경값이 확실하게 반영됩니다.

원인 2: 크론 표현식(Cron Expression) 구문 오류

n8n의 Schedule Trigger는 표준 5자리 크론(분, 시, 일, 월, 요일)을 지원하며, 선택적으로 초(Seconds)를 포함한 6자리도 가능합니다. 문제는 특수문자와 숫자의 조합에서 발생합니다. 예를 들어 매일 9시로 설정한 0 9 * * *를 0 0 9 * *로 적으면 매월 9일 자정에만 실행되며, 요일 필드의 0과 7을 혼동하면 월요일 예약이 일요일로 잘못 등록될 수 있습니다.

검증 방법: 크론 표현식 파싱 도구 사용

crontab.guru 같은 온라인 크론 계산기에 표현식을 붙여넣어 다음 실행 시각을 미리 확인하십시오. 특히 */5가 5분 간격으로 동작하는지, 날짜 필드와 요일 필드가 동시에 있을 때 OR 조건으로 해석되는지(예: 0 9 15 * 1은 매월 15일 또는 매주 월요일 9시에 실행)를 반드시 시뮬레이션해 보는 것이 좋습니다.

희망 실행 주기	흔한 실수 예시	올바른 예시	설명
매일 오전 9시	0 0 9 * *	0 9 * * *	분·시·일 필드 순서를 확인합니다.
매주 월요일 0시	0 0 * * 0	0 0 * * 1	요일 필드에서 0과 7은 일요일로 해석되는 시스템이 많습니다.
5분마다	5 * * * *	*/5 * * * *	5 * * * *는 매시 5분에만 실행됩니다.

원인 3: 비활성화된 스케줄 트리거 (Active 토글)

워크플로우 편집기 상단에는 초록색 Active 스위치가 있습니다. 이 스위치가 꺼져 있으면 아무리 올바른 크론 표현식이라도 실행되지 않습니다. 테스트를 위해 수동 실행(Execute Workflow) 버튼을 누른 후 워크플로우를 저장하는 과정에서 트리거가 자동으로 비활성화되는 일도 자주 있습니다. 특히 JSON으로 워크플로우를 가져오거나 복제한 경우 활성화 상태가 초기화되므로 다시 켜야 합니다.

상태 확인 팁

n8n 대시보드의 워크플로우 목록에서 각 항목의 스위치가 켜져 있는지 시각적으로 확인하십시오. 또한 실행 기록(Executions) 탭에 새로운 로그가 전혀 쌓이지 않는다면 트리거가 비활성화 상태임을 의미합니다. 설정을 수정한 뒤에는 반드시 상단 토글을 다시 Active로 변경하고, 테스트 실행으로 실제 트리거 발화를 확인하는 것이 좋습니다.

원인 4: 리소스 부족 및 워커 프로세스 정지

n8n이 실행 중인 서버의 메모리(RAM)가 부족하면 Node.js 프로세스가 예상보다 늦게 응답하거나 스케줄러 스레드가 블로킹될 수 있습니다. 특히 Docker 컨테이너에서 --restart unless-stopped 옵션 없이 실행 중이라면, 서버 재부팅 후 n8n 프로세스가 자동으로 살아나지 않아 스케줄링이 멈출 수 있습니다. PM2를 사용하는 경우에도 프로세스가 종료된 상태인지 꼭 확인해야 합니다.

점검 및 안정화 방법

SSH에 접속하여 docker logs [컨테이너명], pm2 logs 또는 systemctl status n8n 명령어로 에러 로그와 프로세스 상태를 확인하십시오. 메모리 사용률이 지속적으로 높다면 실행 중인 워크플로우를 줄이거나 서버 리소스를 늘리는 방안을 검토해야 합니다. 또한 운영체제의 크론탭과 n8n의 스케줄러가 같은 시간에 중복 실행되지 않도록 일정을 조정하는 것이 좋습니다.

최종 확인: 무엇부터 손봐야 할까요?

결론적으로 n8n 스케줄 트리거가 예정대로 실행되지 않는(not firing) 상황에서는 감정적으로 대응하기보다 논리적 순서에 따라 점검해야 합니다. 첫 번째로 타임존 설정을 강제하고, 두 번째로 크론 표현식의 다음 실행 시각을 검증하며, 세 번째로 Active 상태를 확인하고, 네 번째로 서버 로그와 리소스를 살펴보십시오. 실제 운영 사례에서도 타임존 불일치와 Active 토글 비활성화가 가장 흔한 원인으로 꼽힙니다.

다음 주 월요일 아침, 당신의 n8n 워크플로우가 정확히 9시에 실행되고 정리된 보고서를 슬랙으로 전송하는 모습을 상상해 보십시오. 지금 설정을 한 번 더 점검하는 몇 분이 매일의 수동 실행을 줄여줄 수 있습니다. 자동화는 신뢰에서 시작되며, 그 신뢰는 세심한 검증에서 비롯됩니다.