WordPressの記事をGitHubへ保存する作業を、毎朝自動で動かすようにしました。次に用意したかったのが、うまく動かなかったときに知らせてもらう仕組みです。
今回は、Healthchecksというサービスを使いました。同期が終わったら完了の合図を送り、予定の時間までに届かなければメールで知らせてもらいます。
自動で保存するところから、動かなかったときにも気づけるようにする。そのために追加したことをまとめます。
自動化の次に生まれた課題
以前、WordPressの過去記事を取り出して、GitHubへ保存する仕組みを作りました。AIに記事を読んでもらい、過去の内容を踏まえて相談できるようにするためです。
その話は、WordPressの記事をREST APIで取り出してGitHubへ同期した記事に書いています。私はエンジニアではないので、AIに手伝ってもらいながら進めています。
続いて、ConoHa WINGのCronで、毎朝4時に同期するようにしました。毎回こちらから頼まなくても、決めた時刻に処理が始まります。記事同期をCronで自動化した話が、その続きです。
ただ、自動で動くようになっても、途中で止まったり、そもそも起動しなかったりする可能性はあります。前の記事でも、失敗したときの通知は課題として残っていました。
そこで今回は、同期が終わったことを外から見守る役目を、Healthchecksに任せることにしました。
「連絡が来ないこと」で異常を察知する
同期の処理に「失敗したらメールを送る」と書いておく方法もあります。ただ、その処理自体が起動しなかったら、メールを送るところまで動きません。
Healthchecksは、外部で完了の連絡を待つサービスです。
正常に終わったら、サーバーから専用のURLへ合図を送ります。予定どおり届いていれば、メールは送りません。届かないまま待ち時間を過ぎると、Healthchecksから私へメールが来ます。その後、復旧したときも知らせてもらいます。
この方法なら、同期サーバー側から何も送れなくなっても、「連絡が来ない」という形で異変に気づけます。
普段の完了連絡はサーバーとHealthchecksの間で済ませ、確認が必要になったら人に知らせる。今回追加したのは、そういう仕組みです。
なお、合図を送るためのURLは記事には載せません。知っている人が合図を送れてしまうので、公開しないようにします。
合図を送るのは、保存が終わってから
ここで大事なのが、どの時点で「終わった」と知らせるかです。
処理が始まっただけで合図を送ると、そのあと保存に失敗しても、Healthchecksには連絡済みになってしまいます。
今回は、同期が正常に終わり、保存完了または変更なしの記録が残り、後片付けまで済んだことを確かめてから送るようにしました。
記事に更新がなければ、保存する内容が増えない日もあります。調べた結果として変更がなかったなら、それも正常な結果です。一方、別の同期が動いていたため今回は処理を見送った、というだけでは成功にしません。
監視サービスを入れるだけでなく、何をもって成功とするかを決める必要がありました。
毎朝4時の同期を、1時間待つ設定に
Healthchecks側も、同期に合わせて毎朝4時、日本時間に設定しました。完了を待つ猶予は1時間です。
4時は処理を始める時刻なので、すぐに保存が終わるわけではありません。処理にかかる時間を見込んで待ち、5時になっても合図が届かなければ異常と判断する設定です。メールの到着時刻には多少の遅れがあり得ます。
設定したあとには、最初の合図が届くところも確認します。一度も受信していない状態では、予定時刻を過ぎても通常の未着監視は始まらないためです。初回の受信では成功メールは来ないので、Healthchecksの画面に残る受信記録で確かめました。
通知を試してから、本番の受信も確認
メールを送る設定にしても、実際に受信できるかは試しておきたいところです。
今回は、本番の記事同期とは別にテスト用のチェックを用意しました。異常と復旧の通知を試し、どちらのメールも受け取れました。本番で障害を起こしたのではなく、知らせが受信箱まで届くかを確認するためのテストです。
本番の初回実行では、朝4時に始まった同期が十数分で終わり、その直後にHealthchecksが完了の合図を受け取ったことも確認できました。
これで、同期からHealthchecksへの連絡と、Healthchecksから私へのメールの両方を確かめられました。
送信結果は不明。でも、合図は届いていた
確認の途中でつまずいたのは、サーバー側に「送信結果が不明」という記録が残ったことです。これだけでは、完了の合図が届いたのか判断できませんでした。
そこでHealthchecks側の記録も確認したところ、合図を受信したことが分かりました。送信側で結果を確定できなかった理由は未解明ですが、到着したことは確認できています。
今回は、送った側の記録だけでは判断できないところを、受け取った側で確かめられました。同期が終わったかどうかと、その知らせが届いたかどうかを分けて見ることが役に立ちました。
自動で動く仕組みに、知らせる仕組みを足せた
毎朝の同期が動かなかったときに、どう気づくか。Healthchecksに完了の合図を待ってもらうことで、予定どおりに連絡が来なければメールで知らせてもらえるようになりました。本番の合図の受信と、テストでの異常・復旧メールまで確認できています。
設定するときに大事だったのは、保存と後片付けが終わってから合図を送ることでした。今後、通知が来たときも、同期の記録とHealthchecksの受信記録を合わせて確認します。
自動で動かすところまでできたら、次は終わったことをどう確かめるかも用意する。記事同期をもう一歩進めるために、今回はこの仕組みを加えました。
自分のAIに頼むなら
すでに自動で動かしている処理があるなら、そこにHealthchecksの監視を追加するところから相談できます。
私の場合は、何を成功とするかを決めることと、通知が本当に届くかを試すことがポイントでした。その点も含めて、次のように頼めば進めやすいと思います。
AIへの依頼文
すでに定期実行している処理に、Healthchecksで外部監視を追加したいです。正常に完了したときに通知を送り、予定の時間までに届かなければ、私にメールで知らせる仕組みにしてください。
監視したい処理：［WordPressの記事をGitHubへ同期する処理など］
動かしている場所：［ConoHa WINGなど］
実行予定：［毎日午前4時・日本時間など］
まず現在のプログラムと設定を確認し、次の順序で進めてください。
- 何をもって正常終了とするかを整理する。処理を開始しただけでは完了通知を送らず、必要な保存と後片付けまで終わってから送る。変更がなかった場合と、実行を見送った場合も区別する。
- 実行時刻・タイムゾーン・通常の所要時間を確認し、完了を待つ猶予を提案する。Healthchecksの登録や通知先の設定など、私の操作が必要な部分は案内する。
- 変更前の状態に戻せるようにしたうえで、既存の処理をなるべく変えずに通知を追加する。通知の送信に失敗しても、完了済みの同期をもう一度実行しない。
- 本番とは別のテスト用チェックで、異常と復旧のメールが届くかを試す。本番の処理をわざと壊してテストしない。
- 最初の定刻実行後に、処理の完了記録とHealthchecksの受信記録を確認する。送信側で結果が分からない場合は、受信側も調べて報告する。
完了通知用のURLや認証情報は、チャット・GitHub・ログ・公開ファイルに残さないでください。権限の変更や料金が発生する操作は、実行前に私へ確認してください。
最後に、通知が来たときに見る場所と、今回追加した監視だけを止める方法を教えてください。実際に確認できたことと、まだ確認できていないことも分けて報告してください。
自分の処理に合わせて調整する
「保存が終わった」の意味や、どれくらい待つかは、動かしている処理によって変わります。私の設定をそのまま使うのではなく、今ある仕組みをAIに確認してもらうところから始めてみてください。
参考資料
Healthchecksの仕様は、2026年10月17日に公式資料を確認しています。稼働実績は、同日の初回実行時点のものです。
Healthchecks：Introductionhttps://healthchecks.io/docs/
Healthchecks：Configuring Checkshttps://healthchecks.io/docs/configuring_checks/
Healthchecks：Monitoring Cron Jobshttps://healthchecks.io/docs/monitoring_cron_jobs/
Healthchecks：Configuring Notificationshttps://healthchecks.io/docs/configuring_notifications/
Healthchecks：公式公開ソース（初回受信前の状態と、状態変化時の通知処理）https://github.com/healthchecks/healthchecks/blob/master/hc/api/models.py
コメント