WordPress에서 예약 글을 등록했는데 발행 시간이 지나도 글이 올라오지 않고 Missed Schedule이라는 상태가 남는 경우가 있습니다. 예약 글이 삭제된 것이 아니라, 예약 시각에 발행 작업을 실행할 WP-Cron 흐름이 제대로 작동하지 않았을 가능성이 큽니다.
이 문제는 단순히 방문자가 적어서 생기는 경우도 있지만 DISABLE_WP_CRON, loopback HTTP 요청, 캐시·WAF, 서버 cron 구성, 예약 이벤트 자체의 문제로 나뉩니다. 아래 순서대로 확인하면 설정을 무작정 바꾸지 않고 원인을 좁힐 수 있습니다.
Missed Schedule이 뜨는 구조부터 이해하기
WordPress의 WP-Cron은 일반적인 Linux cron처럼 항상 실행 중인 백그라운드 프로세스가 아닙니다. 사이트에 요청이 들어오면 WordPress가 예정된 작업이 있는지 확인하고 wp-cron.php 실행을 시도합니다. 방문이 거의 없거나 이 요청이 보안 설정에 막히면 예약 글과 플러그인의 예약 작업이 늦어질 수 있습니다.
즉 Missed Schedule은 예약 글 데이터가 사라졌다는 의미보다 예약 시각에 실행 트리거가 작동하지 않았다는 신호로 보는 편이 정확합니다. 정확한 시각에 실행해야 하는 작업이 많다면 공식 문서가 안내하는 system cron 방식도 함께 검토해야 합니다.
명령을 실행하기 전에 해당 글의 예약 시각과 WordPress 설정 → 일반 → 시간대를 먼저 대조하세요. 관리자 화면의 도구 → 사이트 건강 → 상태에서 예약 이벤트 또는 loopback 요청 문제가 표시되는지도 확인합니다. 예약 시각을 착각한 경우와 실행 경로가 막힌 경우를 구분하기 위한 첫 단계입니다.
첫 진단은 wp cron test
WP-CLI를 사용할 수 있다면 사이트 루트 또는 WordPress가 설치된 환경에서 다음 명령을 실행합니다.
wp cron test이 명령은 DISABLE_WP_CRON과 ALTERNATE_WP_CRON 설정을 확인하고, 실제 WP-Cron spawn 요청을 보내 HTTP 응답을 점검합니다. 성공 메시지가 나오고 HTTP 응답도 정상이라면 자동 실행 경로가 살아 있을 가능성이 큽니다. 반대로 비활성화 설정이나 non-200 응답이 표시되면 아래 설정과 서버·보안 계층을 더 확인해야 합니다.
WP-CLI가 없다면 호스팅의 터미널 기능이나 관리자에게 WP-CLI 사용 가능 여부를 먼저 확인하세요. 명령 결과 전체를 저장해 두면 호스팅 지원을 요청할 때 원인 설명이 쉬워집니다.
예약 이벤트가 실제로 있는지 확인하기
다음으로 예약 작업 목록에 이벤트가 남아 있는지 확인합니다.
wp cron event list출력에서 특히 다음 항목을 봅니다.
예약 시간이 이미 지났는데 이벤트가 계속 목록에 남아 있다면, 이벤트가 등록되지 않은 문제가 아니라 실행되지 못한 상황일 수 있습니다. 특정 플러그인 작업만 멈췄다면 해당 hook을 등록한 플러그인도 함께 확인합니다.
| 확인 항목 | 의미 |
|---|---|
hook | 실행될 작업 이름 |
next_run_gmt | 다음 실행 예정 시각 |
next_run_relative | 현재 시각 기준 남은 시간 또는 지난 시간 |
recurrence | 반복 주기 |
due 이벤트를 수동 실행해 원인 좁히기
실행 시간이 지난 이벤트를 테스트하려면 다음 명령을 사용할 수 있습니다. 이 명령은 현재 실행 대기 중인 모든 cron 작업을 실제로 실행하므로 운영 사이트에서 백업·결제·이메일 작업이 예정돼 있다면 먼저 영향 범위를 확인하세요.
wp cron event run --due-now수동 실행이 성공하면 예약 이벤트와 플러그인 코드가 기본적으로 실행 가능한지 확인하는 데 도움이 됩니다. 이때 자동 예약만 실패한다면 WP-Cron이 wp-cron.php를 호출하는 loopback 요청, 캐시, WAF, 보안 플러그인, 서버 방화벽을 우선 점검합니다.
반대로 수동 실행에서도 특정 hook이 실패하면 해당 플러그인 로그와 PHP 오류, 데이터베이스 상태를 별도로 확인해야 합니다. 모든 이벤트를 반복해서 실행하기 전에 운영 사이트 백업과 테스트 범위를 확인하세요.
wp-config.php의 DISABLE_WP_CRON 확인
wp-config.php에 다음 설정이 있는지 검색합니다.
define( 'DISABLE_WP_CRON', true );이 값이 true라고 해서 무조건 잘못된 것은 아닙니다. Linux system cron이나 호스팅 작업 스케줄러가 이미 wp-cron.php를 일정 간격으로 호출하도록 구성했다면 페이지 방문 때 실행되는 WP-Cron을 끄는 것이 의도된 운영 방식일 수 있습니다.
반대로 별도의 system cron이 없는데 true로 되어 있다면 자동 실행이 끊길 수 있습니다. 설정을 바꾸기 전 현재 cron 작업과 호스팅 패널의 예약 작업을 먼저 확인하고, 파일을 백업한 뒤 한 번에 한 가지씩 변경하세요.
loopback·캐시·WAF·저트래픽을 점검하기
wp cron test에서 HTTP spawn 오류가 나오거나 관리자 화면에서 예약 작업이 계속 밀리면 다음 항목을 순서대로 확인합니다.
- 사이트가 자기 자신의
wp-cron.php를 호출할 때 인증·방화벽·보안 플러그인이 차단하지 않는지 확인합니다. - 페이지 캐시나 서버 캐시가
wp-cron.php요청을 비정상적으로 처리하지 않는지 봅니다. - WAF, 호스팅 방화벽, DNS 또는 SSL 설정이 내부 HTTP 요청을 막지 않는지 호스팅 로그에서 확인합니다.
- 방문자가 적은 사이트라면 예약 시각 전후로 실제 요청이 거의 없었는지 확인합니다.
- PHP 메모리 부족이나 치명적 오류가 있는지 WordPress 디버그 로그와 서버 로그를 확인합니다.
사이트 건강의 loopback 검사에서 오류가 나타난다면 그 상세 메시지와 서버 로그를 함께 보세요. WordPress 공식 문서도 loopback 요청이 WP-Cron을 시작하는 데 사용된다고 설명합니다.
사이트 주소를 외부 도구로 무작정 호출하기보다, 서버 로그와 wp cron test 결과를 함께 보면서 차단 지점을 확인하는 편이 안전합니다.
Linux system cron으로 일정하게 실행하기
정확한 예약 실행이 중요하거나 저트래픽 사이트에서 WP-Cron이 자주 늦는다면 운영체제 cron으로 wp-cron.php를 호출하는 방식을 검토할 수 있습니다. 예를 들어 15분 간격의 기본 형태는 다음과 같습니다.
*/15 * * * * wget --delete-after https://example.com/wp-cron.phpexample.com은 실제 사이트 주소로 바꿔야 합니다. 먼저 호스팅이 제공하는 cron 설정 방식과 PHP·SSL 환경을 확인하고, 테스트 명령이 정상적으로 끝나는지 로그로 확인하세요. system cron이 실제로 안정적으로 호출되는 것을 확인한 뒤에야 DISABLE_WP_CRON을 true로 두는 구성을 적용하는 것이 안전합니다.
호스팅에 cron 메뉴가 있다면 같은 원리로 15분 또는 서비스 요구사항에 맞는 간격을 지정할 수 있습니다. 너무 짧은 간격은 서버 요청을 불필요하게 늘릴 수 있으므로 작업량과 호스팅 제한을 함께 고려해야 합니다.
원인별 확인 순서 요약
가장 중요한 순서는 예약 시각·시간대 → 사이트 건강 → wp cron test → 이벤트 목록 → 필요할 때만 due-now 실행 → 설정·loopback·서버 cron 점검입니다. 이 순서를 지키면 트래픽 문제와 설정 문제, 이벤트·플러그인 문제를 섞어 판단하는 실수를 줄일 수 있습니다.
| 증상 | 먼저 확인할 것 | 다음 조치 |
|---|---|---|
| 예약 글만 가끔 늦게 발행 | 방문량과 WP-Cron 실행 빈도 | system cron 검토 |
| 모든 예약 작업이 멈춤 | wp cron test | 설정·loopback 응답 확인 |
DISABLE_WP_CRON 관련 오류 | wp-config.php와 system cron | 기존 호출 작업을 확인한 뒤 변경 |
| 이벤트가 목록에 계속 남음 | wp cron event list | wp cron event run --due-now로 재현 |
| WP-CLI 수동 실행은 정상 | HTTP loopback·캐시·WAF | 서버·보안 로그 확인 |
확인할 점
명령어와 설정은 서버 환경, WordPress 버전, 호스팅 보안 정책에 따라 결과가 달라질 수 있습니다. wp-config.php를 수정하거나 system cron을 추가하기 전 파일과 현재 예약 작업을 백업하고, 테스트 결과를 확인한 뒤 적용하세요.
자주 묻는 질문
Missed Schedule이 뜨면 글이 삭제된 건가요?
아닙니다. 예약 시각에 발행 작업이 실행되지 않았다는 뜻에 가깝습니다. 글 상태와 예약 시각을 확인한 뒤 WP-Cron 이벤트가 남아 있는지 점검하세요.
DISABLE_WP_CRON을 발견하면 바로 false로 바꿔야 하나요?
아닙니다. 이미 Linux system cron이나 호스팅 작업 스케줄러가 wp-cron.php를 호출하고 있다면 의도적으로 true로 둔 구성일 수 있습니다. 먼저 실제 호출 작업이 있는지 확인하고 백업 후 변경하세요.
wp cron event run –due-now가 성공하면 무엇을 알 수 있나요?
수동 실행이 성공한다면 예약 이벤트나 플러그인 코드보다 자동 WP-Cron spawn 경로, loopback HTTP, 캐시·WAF·보안 설정을 우선 점검할 단서가 됩니다.
방문자가 적은 사이트는 어떻게 안정화하나요?
정확한 실행 시간이 중요하다면 system cron 또는 호스팅 작업 스케줄러로 wp-cron.php를 일정 간격 호출하는 방식을 검토할 수 있습니다. 적용 전 현재 백업과 호스팅의 실행 방식부터 확인하세요.