監視・オブザーバビリティ

Better Stackとは？稼働監視・ステータスページ・ログ管理の仕組みとAPI・Terraform設定例、料金の実額【2026年10月】

Better Stackとは？稼働監視・ステータスページ・ログ管理の仕組みとAPI・Terraform設定例、料金の実額【2026年10月】

Better Stackは、Webサイトやサーバーの稼働監視、障害時のオンコール呼び出し、利用者向けのステータスページ、ログやトレースの収集を1つの画面で扱う監視SaaSです。この記事では、製品の構成を整理したうえで、APIでの監視設定、cronジョブのハートビート監視、HTTP APIでのログ送信、Terraformでのステータスページ管理をコード付きで示します。後半では2026年10月15日時点の料金表から実額を試算し、DatadogやPagerDutyとどう選び分けるかを判断します。

なお、名前が似ている「Better-T-Stack」はTypeScriptのプロジェクトを生成するCLIで、監視とは関係のない別の製品です。そちらを探している場合はBetter-T-Stackの使い方と既定構成を参照してください。

まとめ：Better Stackを選ぶ小規模チームと見送るべき3つの条件

Better Stackが向いているのは、外形監視・オンコール・ステータスページを別々のSaaSで契約している、または何も入れていない数人規模の開発チームです。課金の中心は「障害対応に呼び出される人」の数で、ログやトレースを見るだけのメンバーは無料のため、3〜5人の当番で回す体制なら月100ドル台から一通りそろいます。

見送るのは次の3つの場合です。アプリ内部の性能をトレースで細かく追うAPMが主目的の場合、ログを日本国内に保存する必要がある場合、そしてすでにDatadogなどで監視とオンコールを運用している場合です。テレメトリの保存先は欧州・米国・シンガポールの3地域から選ぶ方式で、日本の選択肢はありません。

Better Stackとは：稼働監視・オンコール・ログを束ねる製品構成

Better Stackは、もともと稼働監視の「Better Uptime」とログ管理の「Logtail」として提供されていた製品を1つのブランドにまとめたサービスです。GitHubの公式Terraformプロバイダは今もbetter-uptimeとlogtailの名前で配布されており、ステータスページの既定のサブドメインもbetteruptime.comのままです。古い記事で旧名称を見かけたら、同じ製品の話だと読み替えて問題ありません。

Uptime側：外形監視・ハートビート・オンコール・ステータスページの4機能

Uptime側は、外部からURLやポートに定期的にアクセスする外形監視、定期実行ジョブからの通知を待つハートビート監視、障害時に当番を電話やSMSで呼び出すオンコール、利用者に稼働状況を知らせるステータスページの4つで構成されます。監視で障害を検知するとインシデントが起票され、そのままオンコールの呼び出しとステータスページの表示に連動する流れです。外形監視そのものの考え方は外形監視と内部監視の違いで整理しています。

Telemetry側：ログ・トレース・メトリクスとエラー追跡の守備範囲

Telemetry側は、ログ・トレース・メトリクスを取り込んでSQLやダッシュボードで調べる機能群です。公式の料金ページには、ブラウザのエラー追跡とセッションリプレイ、Playwrightによるトランザクション監視も並んでいます。ただし中心はログで、DatadogやDynatraceのような言語別の自動計装による詳細なAPMとは厚みが違います。

Better StackのUptime APIで外形監視モニターを作成する手順

監視の設定は画面からでも作れますが、対象が10件を超えると手作業の登録漏れが起きます。ここではAPIで作成する方法を示します。APIトークンはチームの設定画面で発行し、環境変数BETTERSTACK_TOKENに入れておく前提です。

curlでステータスコード監視をBetter Stackへ登録するリクエスト例

Create monitor APIのリファレンスによると、エンドポイントはPOST https://incidents.betterstack.com/api/v2/monitorsで、Bearerトークンで認証します。次の例は、2xx応答かどうかを60秒ごとにアジアと米国から確かめる設定です。

curl --request POST \
  --url https://incidents.betterstack.com/api/v2/monitors \
  --header "Authorization: Bearer $BETTERSTACK_TOKEN" \
  --header 'Content-Type: application/json' \
  --data '{
    "monitor_type": "status",
    "url": "https://example.com/healthz",
    "pronounceable_name": "本番APIのヘルスチェック",
    "check_frequency": 60,
    "regions": ["as", "us"],
    "confirmation_period": 120,
    "email": true,
    "sms": false,
    "call": true
  }'

成功すると201とモニターのJSONが返り、入力が不正なら422が返ります。全チーム共通のグローバルトークンを使う場合はteam_nameも必須です。

monitor_typeの選び方とconfirmation_periodで誤報を抑える

monitor_typeには、2xxを確かめるstatusのほか、指定の文字列が本文にあるかを見るkeyword、逆に無いことを確かめるkeyword_absence、ping・tcp・dns・smtpなどのポート監視、ブラウザ操作を再生するplaywrightがあります。メンテナンス画面でも200を返すアプリなら、keywordで正常時にだけ出る文字列を確かめるほうが確実です。

confirmation_periodは、失敗を観測してからインシデントを起こすまでの待ち時間（秒・最大86,400）です。0のままだと一瞬の通信エラーで夜中に電話が鳴るため、上の例では120秒に設定しています。check_frequencyはタイムアウト値以上にする必要があり、監視元のregionsはus・eu・as・auから選びます。

Better Stackのハートビート監視でcronジョブの停止と失敗を検知する設定

外形監視では、夜間バッチやバックアップのように外から呼べない処理は見張れません。Cron and heartbeat monitorのドキュメントによると、ハートビート監視はジョブ側から決まった間隔でURLを呼んでもらい、届かなければインシデントを起こす仕組みです。

終了コードを保存してから/failへ送るcrontabとシェルの書き方

ハートビートごとにhttps://incidents.betterstack.com/api/v1/heartbeat/<トークン>形式の秘密のURLが発行されます。成功時はこのURLを呼び、失敗時は末尾に/failか終了コードを付けて呼ぶと、その場で障害として扱われます。

#!/bin/bash
# /opt/jobs/backup_with_heartbeat.sh
HB_URL="https://incidents.betterstack.com/api/v1/heartbeat/${HEARTBEAT_TOKEN}"

output=$(/opt/jobs/backup_database.sh 2>&1)
code=$?   # 次のコマンドで上書きされる前に保存する

# 終了コードをURL末尾に付け、出力の末尾100行を本文に添える
echo "$output" | tail -n 100 | curl -fsS -m 10 --retry 3 \
  --data-binary @- "${HB_URL}/${code}"

# crontab: 毎日2時に実行
# 0 2 * * * /opt/jobs/backup_with_heartbeat.sh >/dev/null 2>&1

公式の例はbackup_output=$(...)の直後に$?を使っています。このように間に別のコマンドを挟む場合は、上のコードのように終了コードを変数へ退避しておかないと、echoやtailの結果である0が送られてしまいます。

実行間隔と猶予期間の決め方：最初の受信まで監視が始まらない点

画面では「Expect a heartbeat every」に実行間隔を、grace periodに遅延の許容時間を設定します。バックアップのように実行時間が日によって変わる処理は、最長の実行時間に余裕を足した値を猶予にします。注意したいのは、ハートビートは最初の1回を受信するまで「Pending」のままで監視が始まらない点です。作成後に一度手で実行して、状態が切り替わったことを確かめてください。

HTTP APIでログを送りTerraformで監視とステータスページをコード化する

ログの取り込みには、Vectorや公式のコレクタ、各言語のライブラリなど多くの経路がありますが、仕組みを理解するにはHTTP APIが近道です。続けて、ここまでの監視とステータスページをTerraformで管理する例を示します。

ソーストークンとNDJSONでログを送るcurlとレスポンスコード

Ingesting logsのドキュメントによると、ログのソースを作ると専用の取り込みホストとソーストークンが発行されます。本文はJSON・NDJSON・MessagePackで送れ、dtに時刻を入れなければ受信時刻が使われます。

cat <<'EOF' > events.ndjson
{"dt":"2026-10-15T02:00:01Z","level":"info","message":"backup started","job":"db-backup"}
{"dt":"2026-10-15T02:14:37Z","level":"error","message":"backup failed","job":"db-backup","exit_code":2}
EOF

curl -X POST "https://${INGESTING_HOST}" \
  -H "Authorization: Bearer ${SOURCE_TOKEN}" \
  -H "Content-Type: application/x-ndjson" \
  --data-binary @events.ndjson

受け付けると202が返ります。402は無料枠か支出上限への到達、403はトークン誤り、406はJSONとして不正、413はサイズ超過です。1リクエストは圧縮後10MiBまで、1件のログは10MiBまでで、公式は1件100KiB以下を推奨しています。402を握りつぶすと上限到達に気づかずログが欠けるため、送信側で警告を出すようにしておくべきです。

better-uptimeプロバイダでモニター・ステータスページを宣言する例

GitHubの公式プロバイダは、Terraform Registryで2026年10月6日公開の0.22.4が最新です。APIトークンは環境変数BETTERUPTIME_API_TOKENでも渡せます。

terraform {
  required_providers {
    betteruptime = {
      source  = "BetterStackHQ/better-uptime"
      version = "~> 0.22"
    }
  }
}

provider "betteruptime" {}   # BETTERUPTIME_API_TOKEN を読む

resource "betteruptime_monitor" "api" {
  url          = "https://example.com/healthz"
  monitor_type = "status"
}

resource "betteruptime_status_page" "this" {
  company_name = "Example, Inc"
  company_url  = "https://example.com"
  timezone     = "UTC"
  subdomain    = "example-status"
}

resource "betteruptime_status_page_resource" "api" {
  status_page_id = betteruptime_status_page.this.id
  resource_id    = betteruptime_monitor.api.id
  resource_type  = "Monitor"
  public_name    = "APIサーバー"
}

betteruptime_status_page_resourceで監視とステータスページを結び付けると、監視の状態がページの表示に反映されます。ステータスページの入門ドキュメントのとおり、ページには監視・ハートビートに加え、外部サービスの稼働状況も並べられます。社内向けに限定したい場合はパスワード保護を使いますが、後述のとおり有料の追加機能です。

Better Stackの料金：Responder課金とテレメトリ従量の実額試算

以下は2026年10月15日に公式の料金ページで確認した値です。ページ自体に改定日の表記はありません。課金は「Responder（呼び出し対象者）の人数」「監視の追加分」「テレメトリのデータ量」の3つを足し合わせる形です。

無料プランの上限とResponderライセンスの月額・電話通知の扱い

  • 無料プラン：監視・ハートビート合計10件、ステータスページ1つ、通知はSlackとメール、ログとトレースは各3GB・保持3日、例外10万件
  • Team member（Telemetryの閲覧・操作）：無料
  • Responder（Uptimeのオンコール対象＋Telemetry）：月払い34ドル、年払い月29ドル。電話・SMS・プッシュ通知は追加料金なし
  • 監視の追加：50件ごとに月払い25ドル、年払い月21ドル。ハートビートは10件ごとに月払い20ドル、年払い月17ドル
  • ステータスページの追加：1ページ月払い15ドル、年払い月12ドル。パスワード保護は1ページ月払い50ドル

60日間の返金保証が付いているため、有料機能はまず月払いで試し、構成が固まってから年払いに切り替えるのが損の少ない順番です。

保存地域で単価が2倍強変わるテレメトリ従量と3人体制の月額試算表

ログとトレースの従量単価は、取り込みが1GBあたり欧州0.10ドル・米国0.15ドル・シンガポール0.35ドル、保持が1GB・月あたり欧州0.05ドル・米国0.08ドル・シンガポール0.18ドルです。日本からの通信距離を気にしてシンガポールを選ぶと、米国の約2.3倍になります。30日保持込みのバンドルも同じ比率で、最小のNano（ログ・トレース・メトリクス各40GB）は年払いで欧州月25ドル、米国月38ドル、シンガポール月88ドルです。

内訳（年払い・米国リージョン） 数量 月額
Responder 3人 87ドル
監視の追加 50件（計60件） 21ドル
ステータスページの追加 1ページ（計2つ） 12ドル
Telemetry Nanoバンドル 各40GB・30日保持 38ドル
合計 － 158ドル

この構成をシンガポールで組むとNanoが月88ドルになり、合計は月208ドルです。費用の差を生むのは人数よりログの量と保存地域なので、取り込む前にデバッグログを送信側で落としておくことが、金額を読めるものにする一番の手段になります。障害調査をAIに任せる「AI SRE」はモデルごとのトークン従量で、これも別建てです。

Better StackとDatadog・PagerDutyの選び分けと採用条件

Better Stackの比較相手は、統合監視のDatadogと、オンコール専業のPagerDutyの2系統です。どちらと比べるかで、判断の軸が変わります。

Datadog・PagerDutyとの比較表：課金単位と守備範囲の違い

観点 Better Stack Datadog PagerDuty
主な課金単位 Responder人数＋データ量 ホスト数＋データ量 ユーザー数
外形監視 あり（10件無料） Synthetics（従量） なし
オンコール Responderに込み On-Call（別料金） 主機能
APM トレース収集のみ 言語別の自動計装 なし

Datadogの全体像はDatadogの仕組みと料金、外形監視の作り方はDatadog Syntheticsの実装手順にまとめています。PagerDutyの実額とOpsgenie終了後の移行先の比較はPagerDuty料金の実額と落とし穴を参照してください。

Better Stackを採用すべき条件：監視とオンコールを一から整える少人数体制

採用するのは、本番障害に気づくのが利用者からの問い合わせ、という状態から抜け出したい数人規模のチームです。外形監視とハートビートで検知し、当番の電話を鳴らし、ステータスページで利用者に知らせる、という一連の流れが1つの契約で組めます。インシデント対応の役割分担やエスカレーションの考え方はインシデント管理のプロセスとオンコールの実装で解説しています。

監視ツールを入れるだけでなく、当番表やエスカレーションの決め方、障害報告の書式まで含めて体制を作りたい場合は、保守運用・内製化支援として、ツール選定から運用ルールづくりまで相談を受けています。

Better Stackを見送る場面：国内保存の要件とAPM・既存監視がある環境

ログに個人情報が含まれ、社内規程や契約で国内保存が求められる場合は見送ります。前述のとおり保存先は欧州・米国・シンガポールで、自社のバケットにデータを保持するオプション（月払い250ドル）もありますが、取り込み先の地域は上記の3つから選ぶ形です。国内で完結させたいなら、自前のAWS東京リージョンなどにGrafana Lokiを立てる構成のほうが要件を満たしやすくなります。

すでにDatadogでAPMとログを運用している環境も、監視のためだけにBetter Stackを足す理由は薄くなります。エラー追跡の比較はBugsnagの仕組みと料金、製品の横並びの選定軸はオブザーバビリティツール比較で整理しています。

Better Stackの導入前によくある質問：無料枠・保存地域・旧名称

Better Stackの検討でよく出る質問に、2026年10月15日時点の公式ドキュメントと料金ページをもとに答えます。

Better Stackは無料で使えますか？

無料プランがあり、監視とハートビートを合わせて10件、ステータスページ1つ、ログ・トレース各3GB（保持3日）まで使えます。ただし通知はSlackとメールだけで、電話やSMSで当番を呼び出すにはResponderライセンス（年払いで1人月29ドル）が必要です。個人の検証には十分ですが、夜間障害に確実に気づきたい本番運用では有料が前提になります。

Better UptimeやLogtailとBetter Stackは別の製品ですか？

同じ製品群です。稼働監視のBetter Uptimeとログ管理のLogtailが、Better Stackという1つのブランドにまとめられました。Terraformプロバイダは今もBetterStackHQ/better-uptimeとBetterStackHQ/logtailの名前で配布されているため、既存のコードを書き換える必要はありません。

Better Stackのデータはどこに保存されますか？

テレメトリ（ログ・トレース・メトリクス）は、欧州・米国・シンガポールのいずれかの地域を選んで保存します。地域によって単価が違い、シンガポールは米国の約2.3倍です。外形監視の監視元は米国・欧州・アジア・オーストラリアから選べます。日本国内の保存先は料金ページに掲載されていません。

ステータスページを社内向けや自社ドメインで公開できますか？

できます。既定ではbetteruptime.comのサブドメインで公開され、設定でstatus.example.comのような自社のサブドメインも使えます。閲覧者を限定するパスワード保護は1ページ月払い50ドル、IPアドレスでの制限とシングルサインオンはそれぞれ1ページ月払い250ドルの追加料金です。監視を持たない告知専用の製品と比べたい場合は、Atlassian Statuspageの仕組みとAPI自動化・料金の実額で違いを確認できます。

Better StackとBetter-T-Stackは関係がありますか？

関係はありません。Better Stackは監視SaaSで、Better-T-StackはTypeScriptのフルスタック構成を対話形式で生成するオープンソースのCLIです。名前が似ているため検索結果が混ざりますが、提供元も用途も異なります。

関連記事

お気に入りに入れた記事の一覧

この記事は以下の記事からリンクされています

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.10.14　テックブログ ブックオフ不正アクセス：約638万人の対象確認と本物メールの見分け方
  2. 2026.10.14　テックブログ Commune不正アクセス：約30.7万人漏えいの対象確認と共通署名鍵の教訓
  3. 2026.10.15　テックブログ リゾートトラスト不正アクセス：会員2.6万件・カハラ横浜3.6万件の対象確認と窓口
  4. 2026.10.09　テックブログ ユニリタの不正アクセス：SaaS文書管理から漏れた顧客の認証情報と回す手順
  5. 2026.10.08　コラム 特定商取引法に基づく表記の書き方：必須15項目のテンプレートと置き場所

RELATED POSTS 関連記事

一覧へ戻る

目次