コンテンツにスキップ
Hagicode Docs
ブログ

Upptime を使用して無料で独自のステータスページを構築する方法

ページを編集
HagiCode for Windows Microsoft Store artwork
HagiCode for Windows is now on Microsoft Store
HagiCode for Windows is officially live on Microsoft Store. Windows users can install it directly from the storefront and stay on the store-managed update path. Open the listing and take a look.
Open Microsoft Store

Upptime を使用して無料で独自のステータスページを構築する方法

モニタリング全体を GitHub リポジトリに移す——Actions はプローブ、リポジトリはデータベース、Pages は CDN、Issues はイベントログ。ゼロサーバー、ゼロ月額費、見て、調べて、記録を残せるステータスサイトを無理やり作り上げる。黒魔法と言うもよし、貧乏人の知恵と言うもよし、とにかく動いている。

背景

十数の外部サービスで構成された小型製品マトリックスを運用する場合、「そもそも繋がっているのか」ということが口癖になることがよくあります。顧客からのフィードバックでアクセスできないと言われ、SSH で入って curl してみると正常である。数分後にまた落ちているが、今度は見ていなかった。商用モニタリング（Pingdom、UptimeRobot の高額プラン、Datadog）もちろん解決できますが、サイトごとに課金されるか、リクエスト回数で課金されるかで、独立開発者にとってはコストと精神的負担があまり割に合いません。

より重要なのは、ステータスページ自体もユーザーが確認できる必要があるということです。理想的な姿は：ドメイン（例：status.hagicode.com）を持ち、各サービスの可用率、応答時間曲線、履歴イベントをリアルタイムで表示し、障害時に自動的に記録を残し、自動的に通知できることです。従来の方法では 4 つ揃える必要があります——cron を実行するサーバー、履歴データを保存するデータベース、フロントエンドサイト、CDN。これら 4 つを並べると、運用コストはすぐに監視対象のサービス自体を上回ってしまい、鶏を割るのに牛刀を使っているようなもので、鶏の方が窮屈だと文句を言うほどです。

これらの課題を解決するために、私たちは決断を下しました：モニタリングソリューション全体を GitHub に移行するのです。この決断がもたらす変化は、あなたが思っているよりも大きいかもしれません——後でゆっくり説明します。

HagiCode について

この記事で共有するソリューションは、HagiCode プロジェクトで試行錯誤して得た経験に基づいています。HagiCode は AI コードアシスタントプロジェクトで、ウェブサイト、ドキュメントサイト、ダウンロードエンドポイントなど十数のパブリックサービスを提供しており、裏では HagiCode-org/site というメインリポジトリによって駆動されています。これらのサイトは安定して利用可能である必要があるため、ステータスモニタリングはオプションではなく必須要件です。以下の Upptime ソリューションは、まさに HagiCode の実際の本番環境で使用されているものです——私が作り上げたものではありません。

分析：Upptime は実際にどのように動作するのか

Upptime の本質は、実際には GitHub リポジトリテンプレートと、テンプレートから生成された 6 つの workflow です。それを理解する鍵は、「誰がいつ、誰を呼び出し、何をどこに出力するか」を明確にすることです。分解して見れば、それほど神秘的ではありません。

データフロー：1 つの設定ファイルですべてを駆動

システム全体は .upptimerc.yml という 1 つの宣言的設定ファイルを中心に回っています。HagiCode の実際の設定構造は、大体次のようになります：

owner: HagiCode-org
repo: upptime


sites:
  - name: HagiCode Website
    url: https://www.hagicode.com
  - name: HagiCode Docs
    url: https://docs.hagicode.com
  - name: Server Package Index
    url: https://index.hagicode.com/server/index.json
  # ... 合計 14 サイト


status-website:
  cname: status.hagicode.com
  logoUrl: https://raw.githubusercontent.com/HagiCode-org/upptime/master/assets/upptime-icon.svg
  name: HagiCode Status
  introTitle: "**HagiCode Status**"
  introMessage: Real-time availability tracking for public HagiCode websites and download endpoints.
  navbar:
    - title: Status
      href: /
    - title: GitHub
      href: https://github.com/$OWNER/$REPO

ここで 2 点、取り出して言う価値があります。第一に、sites はウェブページ（HTML を返す）も純粋な JSON エンドポイント（例：index.json）も監視できます。Upptime は HTTP ステータスコードと応答時間だけを見て、コンテンツ検証は行いません。第二に、cname は status.hagicode.com を指しており、これはそのドメインを所有し、DNS を GitHub Pages に向ける必要があります——タダで使おうが、ドメインは自分で出さなければなりません。

6 つの workflow の役割分担

.github/workflows/ 下のすべてのファイルの上部には警告 Do not edit this file directly! があります——それらはテンプレートから毎週自動更新され、あなたは .upptimerc.yml を変更するだけで済みます。各 workflow は cron でトリガーされ、同じ action upptime/uptime-monitor@v1.42.6 の異なるサブコマンドを呼び出します。役割分担は明確で、心配する必要もありません：

Workflowcronコマンド役割
uptime.yml*/5 * * * *update5 分ごとに稼働チェック、history/*.yml に書き込み
response-time.yml—response-time応答時間統計を計算
graphs.yml—graphs日/週/月/年の PNG 曲線を生成
summary.yml—summaryREADME 内のステータス表を更新
site.yml0 1 * * *site毎日静的サイトを構築し、Pages にデプロイ
update-template.yml0 0 * * *—毎週上流テンプレートを同期

uptime.yml のコア部分で、「プローブ」がどのように動作するかを示しています：

on:
  schedule:
    - cron: "*/5 * * * *"
jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          token: ${{ secrets.GH_PAT || github.token }}
      - name: Check endpoint status
        uses: upptime/uptime-monitor@v1.42.6
        with:
          command: "update"
        env:
          GH_PAT: ${{ secrets.GH_PAT || github.token }}
          SECRETS_CONTEXT: ${{ toJson(secrets) }}

site.yml はもう一歩進んで、peaceiris/actions-gh-pages@v4 を使用してビルド成果物を gh-pages ブランチにプッシュします：

- uses: peaceiris/actions-gh-pages@v4
  with:
    github_token: ${{ secrets.GH_PAT || github.token }}
    publish_dir: "site/status-page/__sapper__/export/"
    user_name: "Upptime Bot"
    user_email: "73812536+upptime-bot@users.noreply.github.com"

データ保存：ファイルがデータベース

モニタリング結果はデータベースに保存されず、ファイルとして直接リポジトリにコミットされます。これは少し荒っぽいように聞こえますが、使用してみると意外と実用的です。各サイトには 3 種類の成果物があります。

ステータススナップショット history/{slug}.yml、例：history/hagi-code-website.yml：

url: https://www.hagicode.com
status: up
code: 200
responseTime: 96
lastUpdated: 2026-06-17T00:22:34.485Z
startTime: 2026-03-24T10:07:32.531Z

shields.io のエンドポイントバッジデータソース api/{slug}/response-time.json、uptime.json：

{"schemaVersion":1,"label":"response time","message":"739 ms","color":"yellow"}

および応答時間曲線図 graphs/{slug}/response-time-{day,week,month,year}.png。

この「ファイル即データベース」という取捨選択は、よく考えられています：書き込みが多く読み取りが少ない、スケールが制御可能（各サイト 1 日約 288 サンプル、増分のみ保存）、バージョン履歴付き、ゼロインフラ。代償は、リポジトリが成長し続けることと、時折それを気にする必要があることくらいです。

イベントと通知：Issues がイベントログ

障害の記録は GitHub Issues に依存し、リポジトリに付属する 2 つのテンプレートと連携します：.github/ISSUE_TEMPLATE/bug_report.md（ユーザーによる障害報告）と maintainance-event.md（計画メンテナンス）。メンテナンステンプレートは frontmatter で時間枠を表現します：

<!--
start: 2021-08-24T13:00:00.220Z
end: 2021-08-24T14:00:00.220Z
expectedDown: google, hacker-news
-->

Upptime はこれらの Issue を解析し、「メンテナンス中」と「過去のイベント」をステータスページと README にレンダリングします。通知は Issue 自身の watch メカニズムに依存し、さらに設定可能な webhook、Slack、Telegram（.upptimerc.yml の上部で notifications を宣言、HagiCode のサンプルリポジトリは現在有効にしていません——できるだけ減らす方針です）を追加できます。

解決：5 ステップでステータスサイトを複製

HagiCode と同様のステータスサイトを複製するには、ゼロから本番まで 5 ステップです。5 ステップと言っても、各ステップは長くありません。焦らず進みましょう。

ステップ 1：テンプレートからリポジトリを作成

git clone してから変更するのではなく、GitHub の「Use this template」を使用してリポジトリを作成します（例：your-org/upptime）。テンプレートには既にすべての workflow、Issue テンプレート、静的サイトの骨格が組み込まれています。ローカルに clone した後、手動で変更が必要なのは .upptimerc.yml だけです——他はそのままにしておきましょう。

ステップ 2：.upptimerc.yml を編集

owner/repo を自分のものに変更し、sites で監視するアドレスをリストアップし、status-website でサイトを設定します。最小限の動作バージョンは大体次のようになります：

owner: your-org
repo: upptime


sites:
  - name: Main Site
    url: https://example.com
  - name: API Health
    url: https://api.example.com/health
    expectedStatusCodes:
      - 200


status-website:
  cname: status.example.com   # ドメインがない場合は削除、デフォルトの your-org.github.io/upptime を使用
  name: Example Status
  introTitle: "**Example Status**"
  introMessage: サービス可用性リアルタイム監視
  navbar:
    - title: Status
      href: /
    - title: GitHub
      href: https://github.com/$OWNER/$REPO

上級項目：expectedStatusCodes で許容されるステータスコードを制限（デフォルトは 200-399）；headers でカスタムリクエストヘッダー（認証が必要なエンドポイント用）；maxResponseTime で遅い応答をマーク。これらは必要に応じて使用すればいいです。

ステップ 3：Secret と権限を設定

workflow はデフォルトで ${{ secrets.GH_PAT || github.token }} を使用します。github.token は基本フローを通せますが、2 つの制限が噛みつきます：

  1. デフォルトのトークンでトリガーされた workflow は下流 workflow をトリガーしません（循環を防ぐため）。これにより「稼働チェック → Issue 作成 → 通知」というチェーンが途中で途切れます。
  2. クロスリポジトリ操作（例：複数組織）の権限が不足しています。

新しい PAT（repo + workflow 権限が必要）を作成し、リポジトリ Secret GH_PAT に保存することをお勧めします。update-template.yml には専用のチェックがあり、GH_PAT がないとテンプレートの自動更新をスキップして warning を出力するため、この secret はオプションではなく、安心の鍵なのです。

ステップ 4：GitHub Pages を有効化

リポジトリ Settings → Pages → Source で Deploy from a branch を選択し、ブランチは gh-pages、ディレクトリは /root を選択します。site.yml は毎日午前 1 時に自動的にビルド成果物をこのブランチにプッシュします。cname を設定した場合、DNS プロバイダーで CNAME レコードを追加して your-org.github.io を指します。

初回は手動でトリガーするのも良いでしょう：Actions ページで「Static Site CI」→ Run workflow を選択し、スケジュールタスクを待つ必要はありません。1 秒でも早く結果を見れれば、1 秒早く安心できます。

ステップ 5：検証とメンテナンス

設定を push した後、Actions で「Uptime CI」が 5 分ごとに実行されているか、history/ に *.yml ファイルが出現し始めたかを確認します。ステータスページのアドレスは https://<your-org>.github.io/upptime/ またはカスタムドメインです。その後はサイト追加、ドメイン変更は .upptimerc.yml の 1 ファイルを変更するだけで済み、workflow は完全自動です。HagiCode はこの 1 年以上、このメカニズムで 14 のエンドポイントの可用性を維持しており、ほとんど気にしていません。

実践：踏んだ坑はすべてあなたのために通り抜けました

以下のいくつかは、HagiCode の実際の運用で蓄積された経験です。書き出して、あなたが遠回りをしないようにします。

実践 1：監視粒度の選択

HagiCode はウェブページ（https://www.hagicode.com）と純粋なデータエンドポイント（https://index.hagicode.com/server/index.json）を同じ sites リストに置いています。JSON エンドポイントに対して、Upptime はリクエストして HTTP ステータスコードを解析しますが、コンテンツ構造を検証しません。「200 を返すがコンテンツが間違っている」という深いチェックが必要な場合、expectedStatusCodes に外部プローブを追加して補完する必要があります。Upptime 自体はブラックボックス HTTP チェックしか行いません——顔色しか見ず、心は読みません。

実践 2：応答時間バッジの妙用

api/{slug}/response-time.json は shields.io の エンドポイントバッジ データソースです。HagiCode の README ではこの URL を大量に引用しています：

https://img.shields.io/endpoint?url=https%3A%2F%2Fraw.githubusercontent.com%2FHagiCode-org%2Fupptime%2FHEAD%2Fapi%2Fhagi-code-website%2Fresponse-time.json

これにより、任意の Markdown（プロジェクト README、ブログ、サードパーティページ）にリアルタイム応答時間バッジを埋め込むことができ、色は message 内の数値と color フィールドで駆動されます。raw ファイルを参照する際は master/main ではなく HEAD を使用すると、ブランチ名変更後の大規模な失効を回避できます——細部に安定が隠れています。

実践 3：リポジトリサイズの制御

5 分ごとに 1 サンプル、1 年で history/ は相当なサイズを蓄積します。Upptime は増分 YAML ではなく全量ログを使用し、比較的抑制されていますが、定期的にリポジトリサイズを確認することをお勧めします。あるサイトの監視価値が低下した場合、sites から削除すれば、対応する履歴ファイルも手動で削除できます。削除したくないとリポジトリはいずれ肥大化します。

実践 4：メンテナンスイベントの実際の使い方

maintainance-event.md は飾りではありません。リリース計画前に、テンプレートに従って Issue を作成し、start/end/expectedDown を埋めると、Upptime はこの期間内の対応サイトを「計画メンテナンス」とマークし、可用率統計に含めず、正常なリリースで 1 年間の SLA を下げるのを防ぎます。HagiCode の expectedDown はカンマ区切りのサイト名リストをサポートし、sites[].name と 1 対 1 に対応します。

実践 5：テンプレート更新とカスタマイズの境界

すべての .github/workflows/*.yml の上部にある Do not edit this file directly! は脅しではありません。update-template.yml は毎週上流テンプレートでこれらのファイルを上書きします。カスタム動作が必要な場合、正しい方法は .upptimerc.yml で公式がサポートする設定項目（skipTopics、customStatusWebsite、runnerSettings など）を使用することであり、workflow を変更することではありません。どうしても workflow を変更する必要がある場合、update-template.yml を無効にするか、テンプレートをフォークして自分で維持する必要があります——後者は無痛アップグレードを失い、得失は自分で衡量します。

実践 6：無料枠の現実的制約

GitHub Actions はパブリックリポジトリに対して無料で制限時間なし、Upptime の設計はまさにこの点を利用しています。プライベートリポジトリには月 2000 分の無料枠がありますが、uptime.yml は 5 分ごとに実行、1 回約 1 分で、これだけで 1 月約 8640 分になり、超過します。したがって Upptime リポジトリは public である必要があり、これは「無料」という言葉の前提です——秘密のために private に設定して、その後請求書を受け取ると、厄介です。

まとめ

冒頭の質問に戻りましょう：一連の外部サービスを監視するのに、安価な解決策はあるのでしょうか？ HagiCode の答えは——あります。しかも安すぎて信じられないほどです。Upptime はモニタリングを 4 つの GitHub ネイティブコンポーネントに分割します：

  • プローブ = GitHub Actions の cron
  • データベース = リポジトリ内の YAML/JSON ファイル
  • CDN = GitHub Pages
  • イベントログ = GitHub Issues

あなたが得るのは：リアルタイム可用率、応答時間曲線、履歴イベント、可用率バッジ、カスタムドメイン、自動通知、すべてゼロサーバー、ゼロ月額費。代償はリポジトリを公開に保ち、時折リポジトリサイズを気にすることです。実際、この代償は、手作りモニタリングに比べるとはるかに軽いです。

このソリューションが動作する理由の背後には、GitHub エコシステムのオープンソースプロジェクトに対する誠実な補助があります。もし複数サイトの小型製品マトリックスを維持しているなら、午後を費やして構築することを強くお勧めします。手作りモニタリングよりはるかに安心です。

参考資料

まとめ

「Upptime を使用して無料で独自のステータスページを構築する方法」を巡り、より安定した推進方法は、まず重要な設定、依存の境界、実装パスを段階的に通し、その後に最適化の詳細を補完することです。

目標、ステップ、検収点が明確になると、このようなソリューションは通常、よりスムーズに実際の配信に入ることができます。

Tags:
相关链接
HagiCode for Windows Microsoft Store artwork
HagiCode for Windows is now on Microsoft Store
HagiCode for Windows is officially live on Microsoft Store. Windows users can install it directly from the storefront and stay on the store-managed update path. Open the listing and take a look.
Open Microsoft Store

开始使用 HagiCode

一次安装，几分钟上手

HagiCode for Windows 在 Microsoft Store 免费提供。打开商店即可安装并保持更新；也可以先对比各版本与定价，再决定从哪个渠道开始。

前往 Microsoft Store 安装 查看版本与定价