WordPressのWP-Cronが動かない原因と直し方｜予約投稿・バックアップを戻す確認順

WordPressで予約した記事が公開されない、バックアップが予定時刻に始まらない、通知や商品データの同期が止まる――これらは別々の不具合に見えて、WP-Cronという定期処理の仕組みが関係している場合があります。

ただし「アクセスが少ないから」「キャッシュのせい」と決めつけると、時刻設定、停止設定、ループバック、プラグインのエラー、サーバー負荷を見落とします。安全な確認順は、処理結果と時刻を保存し、全イベントが止まったのか特定の処理だけ失敗したのかを分けることから始まります。

結果を確認せず、予約投稿の公開ボタンやバックアップ実行を何度も押さないでください。遅れていた処理が同時に動き、記事の二重通知、メールの重複、バックアップの競合、在庫や会員データの二重処理を起こすおそれがあります。

先に結論｜全停止か一部失敗かを分ける

予約投稿やバックアップが実際に完了していないか確認する
予定時刻、現在時刻、WordPressのタイムゾーンを保存する
予約投稿、バックアップ、通知など複数の定期処理を比較する
ツール→サイトヘルスで「予約したイベント」とループバックを確認する
DISABLE_WP_CRONと代替のサーバーcron有無を確認する
WAF、Basic認証、DNS・SSL、セキュリティ設定による自己通信の拒否を調べる
対象イベントのプラグイン、PHPエラー、タイムアウト、重複登録を確認する
原因だけを修正し、一つのテストイベントで再確認する
正確な時刻が必要なら、ホスティング公式手順でシステムcronを検討する

予約記事を今すぐ公開する必要がある場合でも、先に公開状態、URL、通知、SNS・メール連携を確認します。未公開と確認できた記事だけを手動公開し、原因調査用に当初の予約日時と画面を残してください。

WP-Cronは常時動く時計ではない

WordPress公式のCron資料によると、WP-Cronは予約投稿や更新確認など、時刻に応じた処理を扱います。ただしOSのシステムcronのように常時動く仕組みではなく、WordPressへのページ読み込みをきっかけに、期限を迎えたタスクがあるかを確認します。

たとえば14時に予約した処理があっても、その時刻にWordPressまでページ読み込みが届かなければ、次の機会まで実行が遅れることがあります。WP-Cronは指定時刻ぴったりの実行を保証する時計ではなく、期限を過ぎた処理を次の起動機会に実行する待ち行列として理解すると原因を分けやすくなります。

一方で、アクセスが十分あるのに何時間も止まる、毎回同じイベントだけ失敗する、サイトヘルスに継続して警告が出る場合は、低アクセスだけでは説明できません。停止設定、自己通信の拒否、プラグイン側の処理、サーバー負荷などを確認します。

WP-Cronが止まると何が起きるのか

症状	確認する場所	切り分けの手がかり
予約投稿が公開されない	投稿一覧、予約日時、タイムゾーン	記事だけか、他の定期処理も止まるか
バックアップが始まらない	バックアップ履歴、保存先、プラグインログ	イベント未起動か、処理途中の失敗か
メール・通知が遅れる	送信履歴、キュー、通知設定	イベント実行前か、メール送信後の不達か
自動更新・更新確認が遅れる	更新画面、サイトヘルス、ログ	WP-Cronと外部通信のどちらか
商品・会員・統計の同期が止まる	対象プラグインの処理履歴	特定フックだけ失敗しているか
サイトヘルスにイベント失敗	ツール→サイトヘルス	表示されたイベント名と遅延時間

メール通知が遅い場合、WP-Cronが実行されていないケースと、実行後にメールだけ届かないケースを分けます。送信履歴にはあるのに受信できない場合は、WP-Cronではなく配信経路をWordPressからメールが届かないときの確認順で調べます。

最初に処理結果と時刻を保存する

予定していた処理と対象
WordPressに表示された予定日時
実際に気づいた日時とタイムゾーン
投稿、ファイル、メール、外部サービス上の処理結果
サイトヘルスの警告文とイベント名
直前の更新、移行、SSL、DNS、WAF、キャッシュ変更
同時刻のPHP・サーバー・プラグインログ
過去に正常実行した最終日時

「予約投稿に失敗」と表示されても、ページ自体は公開済みで通知だけ止まっている場合があります。対象URLをログアウト状態で開き、投稿ステータス、公開日時、キャッシュ、メールやSNS連携を別々に確認します。

ログを保存するときは、サイトURL、サーバーパス、メールアドレス、APIキー、Cookieなどを公開場所へ貼らないでください。相談用には機密情報を伏せ、イベント名、時刻、エラーコード、直前変更を残します。

時刻設定ミスと実行失敗を分ける

設定→一般を開く
タイムゾーンが運用地域と一致するか確認する
画面に表示されるUTC時刻とローカル時刻を確認する
予約投稿の予定日時と現在日時を比較する
サーバーや外部サービスのログが別タイムゾーンなら換算する
必要な修正後、少し先の時刻でテスト投稿を一つ予約する

WordPress公式のSettings General screenでは、地域に合う都市を選び、UTC時刻とローカル時刻の表示で確認できます。予約時刻がずれるだけで他の定期処理は動くなら、WP-Cron全停止よりタイムゾーンや外部連携側の時刻を先に疑います。

タイムゾーン変更は既存の予約投稿や外部連携に影響する可能性があります。画面を見ずにデータベース時刻を直接書き換えず、現在設定、予約一覧、変更後の表示を記録してください。

サイトヘルスで全体状態を確認する

管理画面の「ツール→サイトヘルス→ステータス」を開き、「予約したイベントは実行中です」「予約したイベントが遅れています」「予約したイベントが失敗しました」などの表示を確認します。イベント名が表示されたら、文字列をそのまま保存します。

WordPressのSite Health実装は、期限を過ぎたイベントを検出し、予約投稿や自動更新が意図どおり動かない可能性を案内します。ただし警告だけで原因プラグインや通信層を断定はできません。WordPressサイトヘルスの見方で重大な問題と推奨改善を分け、表示されたイベントと同時刻の記録を照合します。

比較結果	考えやすい範囲
複数の無関係なイベントが遅い	WP-Cron起動、ループバック、停止設定、サーバー全体
一つのプラグインのイベントだけ失敗	対象プラグインの処理、外部API、データ、PHPエラー
イベントは動くがメールだけ届かない	メール送信・受信・迷惑メール判定
手動実行は成功し自動だけ遅れる	起動頻度、システムcron、ループバック
手動実行もエラーになる	対象処理のコード、権限、外部API、負荷

原因を7段階で切り分ける

順番	確認すること	証拠
1	WordPressのタイムゾーンと予約状態	設定画面、投稿一覧、現在時刻
2	全イベントか特定イベントか	サイトヘルス、機能別履歴
3	WP-Cronが意図的に停止されていないか	`wp-config.php`、サーバーcron設定
4	WordPressから自サイトへ通信できるか	ループバック結果、HTTP状態、アクセスログ
5	WAF・Basic認証・DNS・SSLの拒否	403・401・SSLエラー、WAFイベント
6	対象プラグイン・テーマ・外部APIの失敗	イベント名、PHPログ、プラグインログ
7	重複イベント、長時間処理、リソース不足	イベント一覧、CPU、メモリ、ワーカー、実行時間

イベント一覧を見て、名前が分からないタスクを一括削除しないでください。更新確認、予約投稿、バックアップ、プライバシー処理、EC、会員、メールなど必要な処理が含まれます。対象フック、次回時刻、間隔、提供元、失敗内容を確認してから対応します。

1．DISABLE_WP_CRONと代替cronを確認する

wp-config.phpに次の設定があると、ページ読み込みによるWP-Cron起動は停止します。

define( 'DISABLE_WP_CRON', true );

この設定自体が誤りとは限りません。ホスティングのシステムcronが代わりにwp-cron.phpを定期実行しているなら、意図した構成です。問題は、ページ読み込み起動だけを止め、代替cronが未設定・無効・失敗している状態です。

誰が、いつ、何のために設定したか
ホスティング管理画面にcron設定があるか
実行間隔と対象URL・コマンドが正しいか
最終実行日時と成功・失敗履歴があるか
ドメイン変更やSSL化後も古いURLを呼んでいないか

設定の意味が分からないままfalseへ書き換えたり、同じ定義を複数追加したりしないでください。構成を記録し、ホスティング会社または保守担当へ代替cronの有無を確認します。

2．ループバックと自己通信を確認する

WordPressはバックグラウンド処理の起動に、自分のサイトへHTTPリクエストを送る仕組みを使います。自サイトから自サイトへの通信が失敗すると、公開ページは見えていても予約イベントだけ止まる場合があります。

サイトヘルスにループバック失敗が出ていないか
Basic認証やメンテナンス用パスワードが自己通信を止めていないか
WAF・セキュリティプラグインがサーバー自身の要求を拒否していないか
WordPressアドレスとサイトアドレスが現在のHTTPS URLか
DNSが現在のサーバーへ向いているか
SSL証明書の期限・ホスト名・チェーンに問題がないか
wp-cron.phpへの401・403・404・5xxがアクセスログにないか

WAFを使っている場合は全停止せず、発生時刻、対象URL、HTTP状態、該当ルールを確認します。Cloudflareルールの条件が想定どおりかはCloudflare Rulesが効かないときの確認順で調べられます。

CDNやページキャッシュがあるだけでWP-Cron失敗と断定はできません。ただし閲覧要求がCDNで完結しWordPressへ届かない構成では、その要求はWordPress側の起動機会になりません。キャッシュを全面削除する前に、オリジンへの要求、cronの実行履歴、システムcronの有無を確認します。

3．特定プラグインのイベント失敗を確認する

他のイベントは動き、一つのプラグインに属するイベントだけ失敗する場合、WP-Cron全体を作り直すより、その処理を調べます。イベント名、引数、予定時刻、最終成功、エラーを保存し、プラグインの現行公式資料とサポート情報を確認します。

プラグインが最新の対応版か
ライセンスやAPI認証が切れていないか
外部APIが障害・制限・タイムアウトになっていないか
必要な権限や保存先へ書き込めるか
PHP致命的エラーやメモリ不足がないか
同じイベントが大量に重複登録されていないか
プラグイン停止後も不要イベントが残っていないか

WordPress公式のScheduling WP Cron Eventsは、同じイベントを確認なしで何度も登録すると大量の重複タスクになり得ること、不要になったイベントは解除する必要があることを説明しています。利用者がイベントを一括削除するのではなく、提供元の修正・停止手順を優先します。

4．長時間処理とサーバー負荷を確認する

バックアップ、画像変換、セキュリティスキャン、商品同期、レポート集計が同じ時刻に重なると、PHPワーカー、メモリ、CPU、データベース接続を使い切り、次のイベントまで遅れることがあります。

見るもの	判断の手がかり
CPU・メモリ	失敗時刻だけ上限へ達していないか
PHPワーカー	長時間処理で空きがなくなっていないか
データベース	遅いクエリ、ロック、接続不足がないか
実行時間	ホスティングの上限より長い処理がないか
アクセス・ボット	定期処理とアクセス急増が重なっていないか
イベント間隔	前回が終わる前に次回が始まっていないか

サイト全体が503になる場合はWordPressの503 Service Unavailable、Cloudflare経由の重い処理が524になる場合はCloudflare 524の確認順で、WP-Cron以外の要求も含めて調べます。

原因と確認できた重い処理だけ、実行時刻をずらす、対象を分割する、頻度を見直す、外部キューへ移すなどの対策を行います。タイムアウトやメモリ上限だけを無制限に広げず、処理時間と同時実行を先に測ります。

イベントを安全にテストする

WordPress公式のTesting of WP-Cronは、WP-CLIのイベント一覧・個別実行や、管理用プラグインで予定イベントを確認する方法を案内しています。コマンド操作に慣れていない場合は、ホスティング会社や保守担当へ次の情報を渡します。

サイトURLと対象機能
イベント名
予定日時と最終成功日時
サイトヘルスの表示
手動実行の成功・失敗
同時刻のPHP・Webサーバーログ
DISABLE_WP_CRONの有無
システムcronの設定と最終実行
直前の変更

本番で個別実行する前に、注文、請求、会員、メール、SNS、バックアップなど再実行の副作用を確認します。「テスト実行」が本処理を一度行う機能なら、結果確認なしの繰り返しは危険です。検証環境で代替できる場合は先に試します。

正確な時刻が必要ならシステムcronを検討する

低アクセスのサイトや、予約投稿・バックアップ・在庫同期を安定した間隔で動かしたいサイトでは、OSまたはホスティングのシステムcronからwp-cron.phpを呼ぶ方法があります。WordPress公式のHooking WP-Cron Into the System Task Schedulerも、この構成を案内しています。

現在のWP-Cronとイベント遅延を記録する
ホスティング公式資料で利用可能なcron方式と最短間隔を確認する
バックアップを確認する
システムcronから現在のHTTPS URLまたは指定コマンドを呼ぶ
実行履歴とテストイベントの成功を確認する
代替が動くと確認できてから、ページ読み込みによるWP-Cronを停止する
予約投稿、バックアップ、通知、更新確認を再テストする
設定、間隔、担当、戻し方を記録する

先にDISABLE_WP_CRONを有効にしてから、代替cronを後で設定する順番は避けてください。設定途中の失敗や入力ミスで、すべての定期処理が止まります。代替の成功確認後に内蔵起動を止めます。

設定コマンド、実行ユーザー、HTTP呼び出し可否、最短間隔はサーバーごとに異なります。インターネット上のコマンドをそのまま貼らず、契約中ホスティングの現行公式手順を使ってください。共有サーバーで権限がない場合は、サポートへ設定可否を確認します。

修正後は一度動いただけで終わらせない

確認対象	確認内容
予約投稿	少し先に予約したテスト記事が一度だけ公開される
バックアップ	次回予定で完了し、保存先に復元可能なデータがある
通知・メール	イベント実行後に一度だけ送信・受信される
更新確認	サイトヘルスと更新画面に異常がない
イベント一覧	期限超過と重複が増えていない
サーバー負荷	実行時刻にCPU・メモリ・ワーカーが上限へ張り付かない
ログ	401・403・5xx・PHPエラー・外部API失敗が再発しない
システムcron	予定間隔で成功履歴が継続する

修正直後、翌日、次の定期実行日の3回を目安に確認します。毎時イベントは数回、日次バックアップは次回日次処理まで見ないと、偶然一度だけ成功した状態と区別できません。

再発を防ぐ運用

予約投稿の公開後確認を担当と時刻まで決める
バックアップの「予定」ではなく完了履歴と復元可能性を見る
サイトヘルスの予約イベント警告を月次で確認する
イベント名、提供元、実行間隔、必要性を管理する
停止したプラグインの不要イベントが残っていないか確認する
重い処理を同じ時刻へ集中させない
ドメイン変更、SSL化、WAF変更後に自己通信を再テストする
システムcronの失敗通知または実行履歴を確認する
設定変更日、担当者、戻し方を記録する

バックアップはスケジュール表示だけで安心せず、実ファイルと復元手順まで確認します。基本設計はWordPressバックアップの取り方、更新時の前後確認はWordPress更新の安全手順を参照してください。

月次・四半期の点検へ組み込む場合は、WordPress保守チェックリストの実行記録と担当表へ、予約イベントとシステムcronの確認を追加します。

よくある質問

予約投稿が失敗した記事は手動で公開してよいですか？

公開状態、URL、メール・SNS通知、キャッシュを確認し、未公開と分かった記事だけなら手動公開できます。失敗表示だけを見て連打せず、遅れて自動処理された場合の二重通知や外部連携の重複も確認してください。

アクセスが少ないサイトでは必ず失敗しますか？

必ずではありませんが、ページ読み込みを起動機会にする標準WP-Cronでは、アクセスがない時間帯に処理が遅れることがあります。正確な実行時刻が重要なら、ホスティングが対応するシステムcronを検討します。ただし低アクセスだけで断定せず、停止設定やループバックも確認してください。

WP-Cron管理プラグインを入れれば直りますか？

イベント一覧や個別実行の確認には役立ちますが、WAF、DNS、SSL、サーバー負荷、プラグイン処理のエラー自体を自動で直すとは限りません。調査用プラグインを追加する前にバックアップを取り、利用後に残す必要があるかも見直します。

wp-cron.phpをブラウザーで開けば復旧しますか？

一時的に期限到来タスクが動くことはありますが、原因の解決や継続実行の保証にはなりません。注文・通知・バックアップなど副作用を確認せず何度も実行せず、停止設定、実行履歴、ループバック、個別エラーを調べます。

まとめ｜時計ではなく起動経路と処理結果を見る

WordPressのWP-Cronは、指定時刻に常駐して動く時計ではなく、ページ読み込みなどの機会に期限到来タスクを確認する仕組みです。予約投稿、バックアップ、通知が遅れたら、最初に処理結果、予定時刻、タイムゾーンを保存し、全停止と特定イベント失敗を分けます。

サイトヘルス、DISABLE_WP_CRON、システムcron、ループバック、WAF、対象プラグイン、サーバー負荷を順番に確認してください。修正後は一つのテストで終わらず、次の定期実行まで監視します。予定した処理が一度だけ完了し、遅延・重複・負荷が増えていないことまで確認できて復旧は完了です。