SaaSスタートアップ 2026年4月28日

SaaSスタートアップが5人で24時間監視を回す方法 ─ Heartbeat 活用

5人規模のSaaSスタートアップがMiterlで24時間監視体制を月額1,000円で構築する実例。HTTPエンドポイント・Heartbeat・ステージング/本番分離・外部API依存検知の組み合わせを解説します。

スタートアップ SaaS Heartbeat 監視自動化 API監視

想定するチームと前提条件

シリーズAラウンド前の SaaS スタートアップ「C社」を想定したシナリオです。エンジニア3名 + ビジネス2名の計5人。プロダクトはBtoB SaaS、月額課金モデル、有料顧客 80社、AWS Tokyo リージョンに本番1台 + ステージング1台。

このフェーズでよく聞く悩みが「24時間オンコール体制を組めるほど人がいない」「本番を落とすと顧客が他社に流れる」「Stripe/Auth0/SendGrid など外部APIに依存しているが、そっちの障害には気付きにくい」の3点。Miterlでこれらを月額1,000円程度のコストで解消した運用を紹介します。

監視の3つの軸を最小構成で組む

軸1: 自社プロダクトのHTTP監視

本番のHTTPSエンドポイント（/, /api/health, /api/v1/auth/login）を1分間隔で監視。/api/health には認証無しで 200 OK を返すヘルスチェックを実装し、DB接続・Redis接続・主要外部API疎通を内部でまとめてチェックする設計にしています。

軸2: cron / 定期バッチの Heartbeat 監視

毎日午前3時の請求バッチ、5分おきのメール送信ワーカーなど、裏で動く定期処理は Miterl の Heartbeat エンドポイントに死活ピングを送る形で監視しています。

# crontab
0 3 * * * /app/bin/run_billing.sh && \
  curl -fsS -m 10 --retry 3 https://miterl.com/heartbeat/$BILLING_TOKEN

バッチが失敗するとHTTP CALLが飛ばないため、Miterl側のタイムアウト（例：1時間以内に来なければDOWN）で検知できます。

軸3: 外部API依存のキーワード監視

Stripe・Auth0・SendGrid のステータスページに対するキーワード監視を仕込んでおきます。各社の status ページ HTML 内に「All Systems Operational」など正常時のキーワードがあるはずなので、それが消えたタイミングで検知できます。

# 例：StripeのキーワードMonitorの設定イメージ
URL: https://www.stripestatus.com/
keyword: "All Systems Operational"
match: "must_contain"
interval: 5min

「Stripeが落ちててうちのSaaSの決済が動かない」という顧客問い合わせを受ける前に、開発チャンネルに通知が飛びます。

ステージング/本番の Workspace 分離

C社では本番とステージングを別 Workspace で運用しています。

本番 Workspace: 5人全員 viewer 権限、エンジニア3名 member 権限、CTO のみ owner
ステージング Workspace: エンジニア3名 owner、ビジネス2名アクセス無し

ステージングのDOWNでビジネスメンバーに通知が飛ばないようにしているのと、ステージングの監視を一時的にOFFにしたい時にCTO以外でも操作できるようにする目的です。

デプロイ時の自動メンテナンス

GitHub Actions のデプロイワークフローに、Miterl の Maintenance Webhook を組み込みます。

# .github/workflows/deploy.yml の一部
- name: Pause monitoring
  run: |
    curl -X POST https://miterl.com/api/v1/webhooks/maintenance/${{ secrets.MITERL_TOKEN }}/start \
      -d '{"duration_hours": 1, "name": "Deploy ${{ github.sha }}"}'

- name: Deploy
  run: ./scripts/deploy.sh

- name: Resume monitoring
  if: always()
  run: |
    curl -X POST https://miterl.com/api/v1/webhooks/maintenance/${{ secrets.MITERL_TOKEN }}/end

if: always() でデプロイ失敗時もメンテ解除を呼ぶようにしておくと、ロールバック時の監視ブラックホールを避けられます。

5人で回すオンコールの現実

C社のオンコール運用ルールは以下の通りです。

時間帯	一次対応	エスカレーション
平日09-19時	当番エンジニア（週替わり）	CTO
平日19-09時	エンジニア3名のローテ	全員
土日祝日	エンジニア3名のローテ	全員

夜間・休日のアラートは Slack の #oncall チャンネル + 当番のスマホへSMS。Miterlからの通知設定で「Critical のみSMS、その他はSlackのみ」と分けています。

「全アラートに応答する」のではなく「Criticalだけ即応、それ以外は翌営業日」と明文化することで、5人で回すオンコールが破綻せず1年以上続いています。

月額1,000円で済む理由

C社のMiterl利用は以下の通りで、Plus プラン（月3,300円）よりも軽量な Free プラン + 必要最小限のオプションで運用できています。

HTTP 監視: 5件
Heartbeat: 3件
キーワード監視: 4件（外部APIステータス）
1分間隔チェック
Slack + メール通知

将来 ARR が伸びて顧客SLA 99.9% を契約に明記する段階になれば、Pro プランに切り替えて SLA レポートを顧客提供する流れを想定しています。