止まったことも、その理由も

Maple はサイト、API、ポート、cron ジョブを24時間チェックします。失敗すると理由付きのアラートが届き、失敗した HTTP チェックはアプリ内のリクエストのトレースとして開けます。

動き

モニターをリアルタイムで

バー1本が1回のチェックです。初期設定では2回連続で失敗するとインシデントが開き、チームに通知されます。チェックが再び成功すれば自動で閉じます。

uptime · 5 monitors LIVE

status monitor checks p95 30d

checkout-api GET /health · every 30s 212 ms 99.71%

UP auth GET /v1/session · every 60s 84 ms 99.98%

UP postgres-primary TCP db.internal:5432 · every 30s 3 ms 100%

UP acme.com MX DNS MX acme.com · every 5m 21 ms 100%

UP nightly-backup cron 0 3 * * * · grace 15m n/a 100%

incident opened 14:32:07

checkout-api is down

Status 503, expected 2xx · failed 2 checks in a row

trace 7c1e40a9…e21f service checkout sent to #oncall

failed checks · closes when it passes again http checks carry a trace id

trace 7c1e40a9…e21f 503 · 5.02 s

maple-uptime GET /health 5.02 s

checkout GET /health 4.94 s

checkout pg.pool.acquire 4.90 s

checkout redis GET flags 3 ms

maple.uptime.failureStatus 503, expected 2xx

http.response.status_code503

maple.uptime.monitor_namecheckout-api

url.fullhttps://checkout.acme.dev/health

根本原因

多くの稼働監視ツールは「503」で終わります。Maple の HTTP チェックはトレース ID をアプリに渡すので、アプリが計装されていれば、失敗したチェックはリクエスト全体として開けます。この例では、データベースのプールが接続を渡すまでに5秒かかっていました。

新しく覚えることはなし: HTTP、TCP、DNS のチェックは他のリクエストと同じように保存されます。いつものツールで検索、グラフ化、アラート設定ができます。
サービスと紐づく: モニターをサービスに紐づけると、チェックはそのサービスのページにエラーやデプロイと並んで表示されます。
サービスマップはそのまま: チェックが呼び出し元としてサービスマップに現れることはないので、本当の依存関係が読みやすいままです。

できること

Web サイトと API: ステータスコード、応答時間、本文、JSON のフィールド、ヘッダーをチェック。指定がなければ 2xx 以外はすべて失敗として扱います。
データベースとポート: Postgres、Redis、メッセージブローカー、メールサーバーが接続を受け付けているかを確認します。
DNS レコード: A、AAAA、CNAME、MX、TXT、NS レコードの消失や変更を、ユーザーより先に見つけます。
cron ジョブとワーカー: ジョブは完了時に URL へ ping を送ります。予定どおりに届かなければ Maple がアラートを出します。
最短30秒間隔: 30秒ごとから1時間ごとまで選べ、何回の失敗でアラートを出すかも1〜10回で決められます。
AI エージェントが設定: エージェントは Maple の MCP サーバーからモニターを作成・更新できます。新しいエンドポイントをリリースした直後などに便利です。