Statuspageとは？Atlassianのステータスページの仕組みとAPI自動化・料金の実額【2026年10月】

Statuspageは、Atlassianが提供するステータスページのSaaSです。障害や計画メンテナンスの情報を1つのページにまとめ、メール・SMS・Slack・Webhookで購読者へ届けます。この記事では、コンポーネントやインシデントといった部品の関係を整理したうえで、公開APIで依存先の障害を取得するPythonの例、管理APIでインシデントを起票するcurlの例、監視ツールからの自動更新の仕様を示す構成です。後半では2026年10月15日時点の料金ページから実額を比べ、採用すべき体制と見送る場面を判断します。

まとめ：Statuspageを採用すべき体制と自前の告知ページで足りる条件

Statuspageが向いているのは、BtoBのSaaSや業務システムを外部の顧客へ提供していて、障害の第一報と経過を契約先へ確実に届ける必要がある組織です。購読者へのメール・SMS配信、機能単位の状態表示、計画メンテナンスの予告まで、告知に要る機能がそろっています。

一方で、Statuspageは監視をしません。障害の検知は別の監視ツールが担い、Statuspageへは人かAPIが状態を書き込みます。監視と告知を1つの製品で安く済ませたい少人数チームや、社内向けに稼働状況を見せるだけの用途なら、監視SaaSに付属するステータスページで足ります。

Statuspageとは：監視せず障害の告知だけを担うAtlassianのSaaS

公式のヘルプは、Statuspageを監視ツールではなく障害時のコミュニケーションツールと位置づけています。サーバーやエンドポイントの死活確認はせず、監視ツールとの連携やAPIでページを更新する前提です。GitHubのgithubstatus.comやAtlassian自身のstatus.atlassian.comもこの仕組みで運用されています。

コンポーネント・インシデント・メンテナンス・購読者の4部品の関係

ページは4つの部品でできています。コンポーネントは「API」「管理画面」のように状態を表示する単位で、グループにまとめられます。インシデントは障害の告知と経過の記録、計画メンテナンスは事前予告つきの作業告知、購読者は更新を受け取る宛先です。

インシデントを起票するとき、影響するコンポーネントの状態も同時に変えられます。購読者にはインシデントの作成と更新のたびに通知が届くため、運用の中心となるのはコンポーネントの切り方と通知の頻度です。仕組みの全体像はLearn how Statuspage worksに目次がまとまっています。

公開・非公開・オーディエンス限定の3種類のページと閲覧者の制御

ページは公開（public）、非公開（private）、オーディエンス限定（audience-specific）の3種類から選びます。公開ページは誰でも閲覧でき、非公開ページはログインした利用者だけが見られます。

オーディエンス限定ページは旧称を「Access control」といい、事前に指定したユーザーとグループだけが閲覧・購読できます。顧客企業ごとに見せるコンポーネントを絞れるため、契約先ごとに専用環境を持つBtoBシステムで使われます。現時点では閲覧者ごとに個別のユーザー名とパスワードが必要です。

公開ステータスAPIで依存先SaaSの障害をcurlとPythonで取得する

Statuspageで作られたページは、認証なしで読める公開APIを持っています。自社がGitHubやAtlassian製品に依存しているなら、相手のステータスを機械的に取り込むことが可能です。公開APIの一覧には、summary.json・status.json・components.json・未解決インシデント・予定メンテナンスなど8本のエンドポイントが載っています。

status.jsonとsummary.json：全体4値と機能別状態の取得

全体の状態だけを知りたいときはstatus.jsonを読みます。indicatorはnone・minor・major・criticalの4値です。

curl -s https://status.atlassian.com/api/v2/status.json

2026年10月15日に実行した応答は{"status":{"indicator":"none","description":"All Systems Operational"}}を含んでいました。どの機能が落ちているかまで知るにはsummary.jsonを使い、components配列のstatusがoperational以外のものを拾います。

依存先の障害を自社の監視へ取り込むPythonポーリングの実装例

次の例は、標準ライブラリだけで複数のステータスページを読み、正常でないコンポーネントと進行中のインシデント・メンテナンスを表示します。2026年10月15日にGitHubとAtlassianのページで実行し、どちらもnoneを返すことを確かめました。

import json
import urllib.request

# 依存しているSaaSのステータスページ（いずれもStatuspageで運用）
PAGES = {
    "GitHub": "https://www.githubstatus.com",
    "Atlassian": "https://status.atlassian.com",
}


def fetch_summary(base):
    req = urllib.request.Request(base + "/api/v2/summary.json",
                                 headers={"User-Agent": "status-poller"})
    with urllib.request.urlopen(req, timeout=10) as r:
        return json.load(r)


for name, base in PAGES.items():
    s = fetch_summary(base)
    print(name, s["status"]["indicator"], s["status"]["description"])
    for c in s["components"]:
        if c["status"] != "operational":
            print("  -", c["name"], c["status"])
    for i in s["incidents"]:
        print("  * incident:", i["name"], i["status"], i["impact"])
    for m in s["scheduled_maintenances"]:
        print("  * maintenance:", m["name"], m["scheduled_for"])

cronで5分ごとに回し、出力があればチャットへ流すだけでも、問い合わせが来てから相手の障害に気づく事態は減らせます。自社サービスの外形監視と並べて見る設計は外形監視と内部監視の違いで整理しています。

管理APIでインシデントの起票とコンポーネント状態の更新を自動化する

自社のページを書き換えるには管理APIを使います。Statuspage APIのリファレンスによると、ベースURLはhttps://api.statuspage.io/v1/で、AuthorizationヘッダにOAuthとAPIキーを並べて認証します。APIキーとページIDは管理画面の「API Info」で確認でき、以下では環境変数STATUSPAGE_API_KEYとPAGE_IDに入れておく前提です。

OAuthヘッダのAPIキーでインシデントを作るcurlリクエストと主な項目

インシデントの作成はPOST /pages/{page_id}/incidentsです。次の例は、決済APIの一部障害を「調査中」で起票し、対象コンポーネントをpartial_outageに変えます。

curl -X POST "https://api.statuspage.io/v1/pages/$PAGE_ID/incidents" \
  -H "Authorization: OAuth $STATUSPAGE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "incident": {
      "name": "決済APIの応答遅延",
      "status": "investigating",
      "impact_override": "minor",
      "body": "一部のお客様で決済完了までに時間がかかっています。原因を調査しています。",
      "component_ids": ["COMPONENT_ID"],
      "components": { "COMPONENT_ID": "partial_outage" },
      "deliver_notifications": true
    }
  }'

成功すると201が返ります。statusは通常の障害ならinvestigating・identified・monitoring・resolved、計画メンテナンスならscheduled・in_progress・verifying・completedの中から選びます。nameは255文字、bodyは25,000文字が上限です。

コンポーネント状態5値の使い分けとPATCHで障害を反映する例

インシデントを立てずに状態だけを変えるときはPATCH /pages/{page_id}/components/{component_id}を使います。状態はoperational・degraded_performance・partial_outage・major_outage・under_maintenanceの5値です。

curl -X PATCH "https://api.statuspage.io/v1/pages/$PAGE_ID/components/$COMPONENT_ID" \
  -H "Authorization: OAuth $STATUSPAGE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"component": {"status": "degraded_performance"}}'

実務では、応答が遅いだけならdegraded_performance、一部の顧客や機能が使えないならpartial_outage、全面停止で初めてmajor_outageと決めておくと、当番ごとの判断のぶれが減ります。under_maintenanceは計画メンテナンスの自動遷移に任せ、手で付けないのが無難です。

1秒1リクエストのレート制限と通知を送らない起票の使いどころ

管理APIの制限は、APIキーごとに60秒間の移動平均で毎秒1リクエストです。超えると420または429が返るため、多数のコンポーネントを一斉に書き換える処理は1件ずつ間隔を空けて送ります。

インシデント作成のdeliver_notificationsをfalseにすると、購読者へ通知せずに起票できます。夜間に検知した障害を先にページへ載せ、文面を人が確認してから更新で通知する、という2段階の運用向けの設定です。未解決インシデントの再通知はreminder_intervalsで決まり、APIリファレンス上の既定値は[3, 6, 12, 24]、"[]"を渡すと再通知を止められます。

監視ツールからの自動更新：メール自動化・Webhook・Jira連携の設計

監視ツールとStatuspageをつなぐ経路は、管理APIのほかにメール自動化とWebhookがあります。経路ごとに確実性が違うため、どこまで自動にするかを先に決めます。

件名のUPとDOWNで状態を切り替えるメール自動化の仕様と無視される条件

メール自動化の仕様では、コンポーネントごとに専用のメールアドレスが発行されます。件名に「DOWN」を含むメールが届くとmajor_outage、「UP」なら変更後の状態はoperationalです。アドレスに状態名を付け足すと部分障害や性能低下も指定できますが、その場合UPは効かず、正常へ戻すには元のアドレスへ送ります。

落とし穴は2つあります。ページに進行中のインシデントやメンテナンスがある間は、自動化メールは処理の対象外です。また処理は受信順で、公式は自動化の間隔を1分以上空けるよう求めています。障害が出たり消えたりするフラッピングでは状態の取りこぼしが起きるため、本番の経路にはAPIを選びます。

購読者向けWebhook通知：受信側は30秒以内に2xxを返す

購読者の配信方式にWebhookを有効にすると、コンポーネントの状態が変わるたびにcomponent_update、インシデントが更新されるたびにincidentのペイロードが送られます。Webhook通知のヘルプによると、受信側は初回接続から30秒以内に2xxを返す必要があり、3xxは失敗扱いです。

受信側では重い処理をせず、キューへ積んでから即座に200を返す構成にします。送信元IPは予告なく変わるとされているため、IPの許可リストだけで守る設計は避ける方針です。受信エンドポイントの冪等性の作り方はWebhookの受信側で署名検証と冪等性を実装する方法が参考になります。SlackのIncoming Webhookは宛先にできず、Slackへは専用のSlack購読を使います。

Jira Service Managementのポータルへ障害告知を出す連携の前提

Jira Service Managementとの連携を設定すると、Statuspageで進行中のインシデントやメンテナンス、劣化中のコンポーネントがJSMのカスタマーポータルに表示されます。JSM側のインシデントをStatuspageへリンクして、重複起票を避けることもできます。

前提は、両製品が同じAtlassianサイト上にあり、設定者がStatuspageの管理者かつJSMプロジェクトに入れることです。オーディエンス限定ページでの利用は想定されていません。オンコールを含む検知から収束までの流れはインシデント管理のプロセスと監視・オンコールの実装で解説しています。

Statuspageの料金：無料プランの上限と購読者数で決まる有料プランの実額

料金は「ページの種類」と「購読者数・チームメンバー数」で決まります。以下は2026年10月15日時点の公式料金ページの月額表示です。

公開ページ5プランと非公開ページ4プランの月額・購読者・メンバー比較

オーディエンス限定ページは月額300ドルからで、チームメンバー25人・ユーザー500人からの設定です。非公開ページの購読者はログインした認証済みの人数で数えます。SMSを使いたい時点で公開ページは月額99ドルのStartupが下限になり、ここが実質の入口です。

無料プランで使える機能の上限と購読者の数え方：宛先1件ずつが1人

無料プランの説明によると、Freeは公開ページ専用で、1組織あたり2ページまで作れます。購読者100・チームメンバー2・メトリクス2・コンポーネント25に、メール通知とREST APIが付きます。

購読者の数え方では、メールアドレス・電話番号・Webhookが1件ずつ、Slackは購読したチャンネル1つが1人です。RSSとAtomは数に入りません。有料プランでは有効な購読者だけを数えますが、トライアルでは未確認や削除済みも含めて25人が上限です。顧客企業1社に担当者が5人いれば5人分になるため、契約社数ではなく宛先数で見積もります。

Statuspageを採用する条件と見送る場面：完全自動化しない告知の粒度

Statuspageの価値は、障害時に「誰へ・何を・どの粒度で」伝えるかを製品として固められる点にあります。逆に、その設計を持たないまま入れても、更新されないページが1つ増えるだけです。

Statuspageを採用すべき条件：契約先へ障害の通知義務を負うBtoBの提供者

採用すべきなのは、SLAで障害の通知や稼働率の報告を約束していて、購読者へ確実に配信する仕組みが要る場合です。SLAの定義と稼働率の保証範囲はSLAの定義とSLOとの違いで整理しています。監視の検知からインシデント起票までをAPIでつなぎ、告知文だけ人が書く体制まで作ると、夜間障害でも第一報が遅れません。

監視の設計から当番体制、告知の運用ルールまでを一続きで整えたい場合は、一創の保守運用・内製化支援で既存システムの監視とあわせて設計できます。

見送る場面：監視と告知を1製品で済ませたい少人数体制と社内向けだけの用途

監視ツールをまだ持たない数人規模のチームでは、Statuspageに加えて監視とオンコールを別契約することになり、費用も設定も二重になります。この場合は外形監視・オンコール・ステータスページを1つで持つBetter Stackのステータスページ機能のほうが早く立ち上がります。

社内の利用者へ稼働状況を見せるだけなら、Statuspageは過剰です。非公開ページは月額79ドルからかかり、社内ポータルに監視ツールのダッシュボードを埋め込めば足ります。オンコールの費用感はPagerDuty料金の実額と比べてください。

顧客向け告知の粒度：自動で状態を変え、文面は人が書く半自動の運用

公式は「ステータスページの完全自動化は推奨しない」と明言しています。誤検知・見逃し・文脈の欠如・状態の点滅が、そのまま顧客へ届くためです。実務では、監視ツールからAPIでコンポーネントの状態だけを自動で変え、インシデントの起票と文面は当番が書く半自動の形に落ち着きます。

コンポーネントは社内のサーバー構成ではなく、顧客が契約し利用する機能の単位で切ります。「DBサーバー」ではなく「ログイン」「決済」「帳票出力」のように分けると、購読者は自分に関係する障害かどうかをページを見ただけで判断できます。

Statuspageの導入前によくある質問：無料枠・監視機能・通知の制御

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

Statuspageは無料で使えますか？

使えます。Freeプランは公開ページ専用で、1組織2ページまで、購読者100・チームメンバー2・コンポーネント25・メトリクス2が上限です。通知はメールが中心で、SMSやWebhookでの配信を使うには公開ページなら月額99ドルのStartup以上が必要です。社外向けの小さなサービスなら、この範囲で試せます。

Statuspageは死活監視もしてくれますか？

しません。Statuspageはサーバーやエンドポイントの死活確認を行わない告知専用のツールです。障害の検知はDatadogやPingdom、CloudWatchなどの監視ツールが担い、メール自動化・管理API・各種連携でStatuspageの状態を書き換えます。監視と告知を1製品で持ちたいなら、監視SaaS付属のステータスページを検討します。

購読者に通知せずにインシデントを起票できますか？

できます。管理APIでインシデントを作るときにdeliver_notificationsをfalseにすると、購読者へ通知を送らずにページへ載せられます。夜間の自動起票で誤検知が混ざる環境では、まず通知なしで起票し、当番が内容を確かめてから更新時に通知する運用が安全です。

SlackのIncoming Webhookで障害通知を受け取れますか？

受け取れません。公式ヘルプはSlack宛てのWebhookをサポート対象外としており、代わりにSlack購読を使うよう案内しています。Slack購読で購読者1人に相当するのは、購読したチャンネル1つです。Webhookは自社の受信サーバーで処理する用途に使い、30秒以内に2xxを返す実装にします。

Atlassian StatusやGitHubのステータスページと同じ仕組みですか？

同じ仕組みです。status.atlassian.comやgithubstatus.comはStatuspageで運用されており、/api/v2/summary.jsonなどの公開APIを同じ形式で返します。依存先がStatuspageを使っていれば、同じコードで複数社の障害状況をまとめて取得できます。

関連記事

• Better Stackとは？稼働監視・ステータスページ・ログ管理の仕組みとAPI・Terraform設定例、料金の実額【2026年10月】：監視とステータスページを1製品で持つ選択肢。
• インシデント管理とは？ITIL準拠のプロセスと監視・オンコールの実装を運用目線で解説【2026年版】：検知から告知・収束までの体制づくり。
• SLOとは？SLA・SLIとの違いと設定方法をわかりやすく解説：ステータスページに載せる稼働率の目標の決め方。
• Datadogとは？何ができるか・仕組み・料金とCloudWatch/Zabbixとの違い：Statuspageへ状態を送る側の監視基盤。
• オブザーバビリティツール比較｜選定軸と課金モデル・体制別の選び方【2026年8月時点】：監視製品を課金モデルと体制で選ぶ判断軸。