個人開発アプリ・Webサイトの死活監視と障害通知を自動化する実践ガイド（Cloudflare通知 / 外形監視）
個人開発のWebアプリケーションや技術ブログを公開したあと、意外と見落とされがちなのが 「サイトが正常に表示され続けているかどうかの自動監視（死活監視・外形監視）」 です。
どれほど堅牢なクラウド基盤を使っていても、「DNSレコードの更新ミスで名前解決ができなくなっていた」「デプロイしたスクリプトの例外エラーで特定ページが 500 エラーを返していた」「外部連携APIの仕様変更でフォームが動かなくなっていた」といったトラブルは起こり得ます。さらに、Google Search Console のクローラーや広告審査ボットが巡回したタイミングでサイトが応答不能になっていると、インデックス除外や審査落ちの直接の原因にもなります。
本記事では、コストをかけずに即座に導入できる Cloudflare 標準のアラート通知機能 と、外部からの HTTP 外形監視（Uptime Monitoring）＋ Discord / Slack 通知連携 の構築手順を解説します。
1. 個人開発・技術サイトで最低限監視すべき4つの項目
大規模な商用システムのような複雑な APM（Application Performance Monitoring）を導入しなくても、以下の4項目さえ押さえておけば、致命的な機会損失の99%を防ぐことができます。
| 監視レイヤー | チェックする内容 | 異常時の主な原因例 |
|---|---|---|
| ① HTTP ステータス監視 | トップページおよび主要APIが 200 OK を返すか | デプロイ失敗、Worker例外、ルーティング設定ミス |
| ② レスポンスタイム監視 | 応答時間がしきい値（例：2,000ms）を超えていないか | オリジンサーバーの高負荷、外部APIのタイムアウト待ち |
| ③ SSL/TLS 証明書期限監視 | 証明書の有効期限が残り14日を切っていないか | DNSレコード変更やCAA設定不備による自動更新失敗 |
| ④ キーワード（DOM）存在監視 | HTML内に特定の文字列（サイト名やフッター文字列）が含まれるか | ステータスは 200 だが中身が白紙やエラー画面になる「サイレント障害」の検知 |
2. Cloudflare ダッシュボード標準の「通知（Notifications）」を有効化する
ドメインとサイトを Cloudflare で運用している場合、外部ツールを入れる前にまず設定すべきなのが Cloudflare ダッシュボード左メニューの 「通知（Notifications）」 です。無料プラン（Free Plan）でも以下の重要なアラートをメールや Webhook（Discord / Slack 等）で受け取ることができます。
必ず ON にしておくべき Cloudflare 標準アラート3選
- ユニバーサル SSL アラート（Universal SSL Alert）
SSL 証明書の発行・更新・削除に関するイベントが発生した際に通知されます。万が一証明書の自動更新で検証エラーが起きた場合に即座に気づくことができます。 - HTTP DDoS 攻撃アラート（HTTP DDoS Attack Alert）
自サイトに対して異常な規模の HTTP リクエスト攻撃が検知され、Cloudflare が自動緩和（Mitigation）を発動した際に通知されます。 - Workers / Pages のデプロイ・クォータ通知
無料枠のリクエスト上限に近づいた場合や、ビルド・デプロイ失敗時にメールを受け取る設定です。
3. Cloudflare Workers の Cron Triggers で自作する軽量外形監視（Webhook通知付き）
外部の監視SaaSに頼らず、自分の Cloudflare アカウント内の Cron Triggers（定期実行 Worker） を使って、5分おきに自サイトの主要ページ（トップページ、記事ページ、sitemap-index.xml）を巡回し、異常時のみ Discord や Slack の Webhook へ通知する仕組みも簡単に構築できます。
3.1 監視用 Worker スクリプトの実装例
以下は、監視対象URLのリストを並列チェックし、ステータスコードが 200 以外だった場合や応答に3秒以上かかった場合に Discord Webhook へ警告を送る TypeScript コード例です。
export interface Env {
DISCORD_WEBHOOK_URL: string;
}
const TARGET_URLS = [
'https://egpl.net/',
'https://egpl.net/blog/',
'https://egpl.net/sitemap-index.xml',
];
export default {
async scheduled(event: ScheduledEvent, env: Env, ctx: ExecutionContext): Promise<void> {
const failures: string[] = [];
for (const url of TARGET_URLS) {
const start = Date.now();
try {
const res = await fetch(url, {
headers: { 'User-Agent': 'EGPL-Uptime-Monitor/1.0' },
});
const elapsed = Date.now() - start;
if (res.status !== 200) {
failures.push(`❌ ${url} returned HTTP ${res.status} (${elapsed}ms)`);
} else if (elapsed > 3000) {
failures.push(`⚠️ ${url} slow response: ${elapsed}ms`);
}
} catch (err) {
failures.push(`🚨 ${url} fetch error: ${String(err)}`);
}
}
if (failures.length > 0 && env.DISCORD_WEBHOOK_URL) {
await fetch(env.DISCORD_WEBHOOK_URL, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
content: `**[Uptime Alert]** サイト監視で異常を検知しました:\n${failures.join('\n')}`,
}),
});
}
},
};3.2 wrangler.jsonc での Cron スケジュール設定
5分間隔で定期実行する場合は、triggers.crons に */5 * * * * を指定します。
{
"name": "egpl-uptime-monitor",
"main": "src/monitor.ts",
"compatibility_date": "2026-10-01",
"triggers": {
"crons": ["*/5 * * * *"]
}
}1日あたりの実行回数は 12回/時 × 24時間 = 288回 となり、Cloudflare Workers の無料枠（1日10万リクエスト）のわずか 0.3% 未満で完全に無料運用できます。
4. デプロイパイプラインに「ビルド後のスモークテスト」を組み込む
障害が起きてから検知するだけでなく、「壊れた状態を本番環境へデプロイしない」 ための予防策として、ビルド直後に主要HTMLファイルと sitemap-index.xml が正しく生成されているかをチェックするスモークテスト（Smoke Test）を挟むのが効果的です。
たとえば package.json のデプロイスクリプトを実行する際、以下の3点を自動検証できます。
# ビルド出力（dist/）に必須ページとサイトマップが存在するか検証するワンライナー
test -f dist/index.html && \
test -f dist/privacy/index.html && \
test -f dist/contact/index.html && \
test -f dist/sitemap-index.xml && \
echo "✅ Smoke test passed!"とくに Astro と Cloudflare Pages の自動デプロイ構成 では、Markdown の Frontmatter（公開日やカテゴリ名）の記述ミスがあるとビルド自体がエラーで停止して本番環境を保護してくれますが、ルーティング変更時などに必須ページが欠落していないかをチェックする仕組みを入れておくとさらに盤石です。
5. 監視ボットがアクセス解析のノイズにならないための配慮
外形監視ツールを5分おきに動かすと、1日に約300回、月間で約9,000回のアクセスが発生します。
- HTML に対して JavaScript を実行しない
fetch（HTTP GET / HEAD）監視：ブラウザ上で動く Google Analytics (GA4) や Google AdSense のスクリプトは実行されないため、PV数や広告インプレッションを汚染することはありません。 - サーバーサイドのログや Cloudflare Analytics で除外したい場合：監視リクエストに固有の
User-Agent（例：EGPL-Uptime-Monitor/1.0）を付与しておけば、後からフィルタリングで簡単に除外できます。
まとめ
個人開発のアプリやメディアを長く安定して育てていくためには、「いつ見ても高速かつ正常に表示される信頼性」がすべての土台になります。まずは Cloudflare 標準の SSL・DDoS 通知を ON にし、主要 URL の定期ヘルスチェックを導入して、安心して開発と記事執筆に集中できる環境を整えましょう。