予定アクションが詰まった WooCommerce ストア
何千もの予定アクションが待機中のままで、メールが遅れて届きます。LayerAssist は失敗しているアクションを見つけてキューを動かし、本物の Cron を設定します。
定期タスクが本当に動いているか確かめる。
バックアップ、メール、インポート、予約投稿。サイトの仕事の多くはスケジュールに沿って裏側で動いています。LayerAssist はそれらが動いているかを確認し、動かなかった理由を突き止めて、再び動かします。
ひと目で分かるポイント
- チャットでチャットでは、Cron ジョブを一覧にしてログを読み、WordPress のスケジューラーとバックグラウンド処理を確認し、動いていないタスクを直します。
- 自動化独自の自動化として、毎朝、夜間のタスクが実行されたか――たとえば新しいバックアップがあるか――を確認し、動いていないものがあればお知らせできます。
- 内蔵モニターキューのワーカーがサービスとして動いていれば、内蔵のサービスモニターが止まった瞬間にお知らせします。
- 未対応Cron ジョブ向けの内蔵「ハートビート」モニターは、まだありません。
バックグラウンドのタスクは、音もなく失敗する
Cron ジョブやキューは、誰も見ていないときに動いています。夜間のバックアップ、請求書のメール、商品のインポート、キャッシュの掃除、予約投稿。どれかが止まってもエラーページは出ません。ただ、その仕事が行われないだけです。
気づくのはあとになってから、しかも一番つらい形で。必要なバックアップは 3 か月前のもの、お客様に請求書が届いていない、朝の記事が公開されていない。
定期タスクが動いていないサイン
- バックアップが作られていない、または本来より古い
- 予約投稿に「予約の失敗」と表示される
- 毎日のメールやエクスポートが止まった
- キューが伸び続け、タスクが「待機中」のまま
Cron ジョブとキューが止まる理由
WordPress のスケジューラーはアクセスがあるときだけ動く
WP-Cron は誰かがサイトを訪れたときに動きます。アクセスの少ないサイトやキャッシュの背後では、予約されたタスクが遅れて実行されるか、まったく実行されません。
パスや実行環境の誤り
手動では動くタスクが、PHP のバージョンの違い、足りないパス、移動したスクリプトのせいで、スケジュール実行では失敗します。
ワーカーのプロセスが停止
キューのワーカーは常に動いている必要があります。クラッシュ、デプロイ、再起動のあと、誰もそれを起動し直しません。
クラッシュや重なり合うタスク
失敗した 1 つのタスク、解放されないロック、間隔より長くかかるタスクが、後ろのすべてを止めてしまいます。
LayerAssist がバックグラウンドのタスクを動かし続ける方法
スケジュール、ログ、そして結果――タスクが生み出すはずのもの――を確認します。
予定されているものを一覧に
サーバーの crontab、ホスティングのコントロールパネルの Cron ジョブ、WordPress の予定イベントを読み取り、それぞれを説明します。
本当に実行されたか確認
証拠を探します。ログの記録、新しいバックアップファイル、送信済みのメール、空になったキュー。
失敗した理由を探す
Cron と同じ方法でタスクのコマンドを実行し、エラーを読み、パス、PHP のバージョン、アクセス権を直します。
正しく設定する
WP-Cron を本物のサーバーの Cron に置き換え、自動で再起動するワーカーを設定し、失敗が記録に残るようにログを追加できます。
例：いつの間にか作られなくなったバックアップ
確認したこと
- crontab：バックアップは毎晩 02:00 に予定されている
- 最新のバックアップファイル：74 日前のもの
- Cron のログ：タスクが「mysqldump: command not found」で失敗
- 原因：サーバーの更新でツールの場所が変わり、タスクは古いパスのまま
変更したこと
バックアップスクリプトのパスを直して一度実行し、失敗時にメールが届くよう設定しました
得られること
- 予定されているだけでなく、実行されたことの証拠
- 失敗に気づくのは数か月後ではなく翌朝
- 時間どおりに動く WordPress の予約タスク
- クラッシュのあとに戻ってくるキューのワーカー
実際の使用例
キューを使う Laravel アプリ
デプロイのあと、キューのワーカーが二度と起動しませんでした。LayerAssist は自動で再起動するよう supervisor の管理下に置き、サービスモニターを提案します。
予約記事のあるニュースサイト
6:00 に予約した記事が昼に公開されていました。キャッシュの背後では、WP-Cron はキャッシュが切れたときにしか動かなかったのです。サーバーの Cron で解決します。
LayerAssist で Cron ジョブを確認する方法
サーバーやホスティングを接続
SSH なら全体像が分かります。ホスティングのコントロールパネルでも、そこで設定された Cron ジョブが見られます。
チェックを依頼
チャットで：「予定しているタスクは動いていますか？」または「昨夜のインポートはなぜ失敗したのですか？」
タスクの修正を任せる
原因を見つけて直し、動くことを証明するためにタスクを一度実行します。
毎朝のチェックにする
毎日のチェックを独自の自動化として依頼し、サービスとして動くキューのワーカーにはサービスモニターを追加します。
Cron ジョブ監視についてのよくある質問
Cron はサーバー自身のスケジューラーで、時間どおりに動きます。WP-Cron は WordPress に組み込まれたスケジューラーで、誰かがサイトを訪れたときにだけ動きます。確実なスケジュールのために、LayerAssist は本物のサーバーの Cron から WP-Cron を動かせます。
はい、SSH アクセスがあれば対応します。ワーカーのプロセス、失敗したジョブ、キューの長さを確認し、自動で再起動するよう Supervisor や systemd の下でワーカーを動かせます。
独自の自動化としての定期チェックで可能です。たとえば毎朝、タスクが動いた証拠を探し、足りないものがあればお知らせします。内蔵の「ハートビート」モニターはまだありません。
自分のユーザーの Cron ジョブやログを読むだけなら、通常のアクセスで十分です。システムサービスや他のユーザーのタスクを変更するには sudo が必要で、Plus 以上のプランで利用できます。
月額 $9 から · 14 日間の返金保証
次に何か壊れても、誰に聞けばいいか分かります。
今日サイトを追加して、最初の質問をしてみましょう。合わなければ 14 日以内に解約すれば初回支払いが戻ります（差し引くのは使用した AI 処理分のみ）。
7 日間無料 · クレジットカード不要 · 専門知識は必要ありません。