Как использовать Upptime для бесплатного создания собственной страницы состояния

18 июн. 2026 г.

Участие ИИ

ИИ помогал в написании, редактировании или проверке этой страницы.

Внимательно оценивайте важные детали и при необходимости сверяйте критические решения с первоисточниками.

Как использовать Upptime для бесплатного создания собственной страницы состояния

Переносим весь процесс мониторинга в репозиторий GitHub — Actions как зонд, репозиторий как база данных, Pages как CDN, Issues как журнал событий. Ноль серверов, ноль ежемесячных платежей — получаем рабочую страницу состояния с возможностью просмотра, поиска и сохранения истории. Называйте это чёрной магией или хитростью бедняка — главное, это работает.

Предпосылки

При эксплуатации небольшой матрицы продуктов, состоящей из более десяти внешних сервисов, вопрос “работает или нет” часто стал повторяться. Клиенты сообщают, что не могут получить доступ, вы подключаетесь через SSH, делаете curl, и всё работает; через несколько минут снова падает, но вы в этот момент не следите. Коммерческий мониторинг (Pingdom, премиум-версия UptimeRobot, Datadog), конечно, может решить проблему, но оплата либо за сайты, либо за количество запросов — для независимого разработчика это не совсем выгодно ни по стоимости, ни по ментальной нагрузке.

Что ещё важнее, сама страница состояния должна быть доступна для пользователей пользователям. Идеальный вид: домен (например, status.hagicode.com), в реальном времени показывающий доступность каждого сервиса, кривую времени отклика, исторические события, при сбоях автоматически сохраняющий историю и уведомляющий. Традиционный подход требует набора из четырёх компонентов — сервер с cron, база данных для хранения истории, фронтенд-сайт, CDN. Как только эти четыре компонента развёрнуты, эксплуатационные расходы сразу перекрывают сами контролируемые сервисы — ведь резать курицу ножом для баранины, да ещё и курица теснится.

Чтобы решить эти проблемы, мы приняли решение: весь план мониторинга напрямую перенести на GitHub. Это решение принесло изменения, возможно больше, чем вы ожидали — позже я расскажу подробно.

О HagiCode

Решение, описанное в этой статье, получено из нашего опыта работы над проектом HagiCode. HagiCode — это проект AI-помощника по коду, предоставляющий десятки общедоступных сервисов: веб-сайт, документация, конечные точки загрузки и т.д., управляемый основным репозиторием HagiCode-org/site. Эти сайты должны быть стабильно доступны, поэтому мониторинг состояния для нас — не опция, а необходимость. Ниже описанное решение Upptime — это то, что использует HagiCode в реальной производственной среде — не я придумал.

Анализ: как на самом деле работает Upptime

Суть Upptime — это шаблон репозитория GitHub плюс шесть workflow, генерируемых шаблоном. Ключ к пониманию — увидеть “кто когда, кого вызывает, что производит и куда складывает”. Разобрав по частям, это уже не так загадочно.

Поток данных: один файл конфигурации управляет всем

Вся система вращается вокруг одного декларативного файла конфигурации .upptimerc.yml. Реальная структура конфигурации 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

Здесь стоит отметить два момента. Во-первых, sites может отслеживать как веб-страницы (возвращающие HTML), так и чистые JSON-эндпоинты (например, index.json) — Upptime смотрит только на код состояния HTTP и время отклика, не проверяя содержимое. Во-вторых, cname указывает на status.hagicode.com, что требует владения этим доменом и настройки DNS指向 GitHub Pages —毕竟 даже бесплатно, домен всё равно придётся купить.

Разделение между шестью workflow

Вверху всех файлов в .github/workflows/ есть предупреждение Do not edit this file directly! — они автоматически обновляются шаблоном каждую неделю, вы редактируете только .upptimerc.yml. Каждый workflow запускается по cron, вызывает различные подкоманды одного и того же действия upptime/uptime-monitor@v1.42.6, разделение чёткое, что и экономит силы:

Workflow	cron	команда	действие
uptime.yml	*/5 * * * *	update	проверка доступности каждые 5 минут, запись в history/*.yml
response-time.yml	—	response-time	расчёт статистики времени отклика
graphs.yml	—	graphs	генерация PNG-графиков за день/неделю/месяц/год
summary.yml	—	summary	обновление таблицы состояния в README
site.yml	0 1 * * *	site	ежедневная сборка статического сайта, развёртывание в Pages
update-template.yml	0 0 * * *	—	еженедельная синхронизация с шаблоном upstream

Основной фрагмент 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"

Сохранение данных: файлы как база данных

Результаты мониторинга не хранятся в базе данных, а сразу commit-ятся обратно в репозиторий в виде файлов. Звучит диковато, но на деле надёжно. У каждого сайта есть три типа артефактов.

Снимок состояния 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 endpoint 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.

Этот компромисс “файлы как база данных” на самом деле хорошо обдуман: много операций записи, мало чтения, контролируемый масштаб (около 288 выборок в день для каждого сайта, хранение инкрементов, а не полных данных), естественная история версий, нулевая инфраструктура. Цена — репозиторий будет постоянно расти, иногда придётся заглянуть и позаботиться о нём.

События и уведомления: Issues как журнал событий

Сохранение истории сбоев relies на GitHub Issues, вместе с двумя встроенными шаблонами репозитория: .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 будет анализировать эти Issues и отображать “планируемое обслуживание” и “прошедшие события” на странице состояния и в README. Уведомления основываются на механизме watch самого Issue, плюс настраиваемые webhook, Slack, Telegram (в .upptimerc.yml вверху объявляется notifications, примерный репозиторий HagiCode пока не включил — ведь чем меньше, тем лучше).

Решение: пять шагов для воспроизведения страницы состояния

Чтобы воспроизвести страницу состояния в стиле HagiCode, от нуля до запуска — всего пять шагов. Хотя это пять шагов, на самом деле каждый шаг не длинный, идём не спеша.

Шаг 1: создание репозитория из шаблона

Не делайте git clone и потом редактируйте, а напрямую используйте “Use this template” на GitHub для создания репозитория (например, your-org/upptime). В шаблоне уже встроены все workflow, шаблоны Issues и скелет статического сайта. После 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   # без домена можно удалить, используется default 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 может справиться с базовым процессом, но есть два ограничения, которые могут укусить:

1. workflow, запускаемый default token, не будет запускать downstream 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, добавьте запись CNAME в вашем DNS-провайдере, указывающую на your-org.github.io.

Впервые вручную запустить тоже хорошо: на странице Actions найдите “Static Site CI” → Run workflow, не нужно глупо ждать запланированную задачу — ведь чем раньше увидите результат, тем раньше почувствуете спокойствие.

Шаг 5: проверка и обслуживание

После push конфигурации перейдите в Actions, проверьте, запускается ли “Uptime CI” каждые 5 минут, начинают ли появляться файлы *.yml в history/. Адрес страницы состояния — это https://<your-org>.github.io/upptime/ или ваш кастомный домен. В дальнейшем добавление сайтов, изменение домена — нужно редактировать только один файл .upptimerc.yml, workflow полностью автоматические. HagiCode уже больше года поддерживает доступность 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 — это источник данных для endpoint значков shields.io. В README HagiCode широко используются такие 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. Обратите внимание: используйте HEAD вместо master/main для ссылки на raw-файлы, чтобы избежать массового сбоя после переименования ветки — в деталях скрывается стабильность.

Практика 3: контроль объёма репозитория

Выборка каждые 5 минут, за год history/ накопит заметный объём. Upptime использует инкрементный YAML вместо полных логов, относительно сдержанно, но всё равно рекомендуется периодически проверять размер репозитория. Если ценность мониторинга какого-то сайта упала, просто удалите его из sites, соответствующие исторические файлы также можно вручную очистить — ведь если жалеете удалять, репозиторий рано или поздно раздуется для вас.

Практика 4: реальное использование событий обслуживания

maintainance-event.md не для украшения. Перед запланированным релизом создайте Issue по шаблону, заполните start/end/expectedDown, Upptime пометит соответствующие сайты в это время как “планируемое обслуживание”, не учитывая в статистике доступности, чтобы избежать снижения годового SLA из-за нормального релиза. expectedDown в HagiCode поддерживает список названий сайтов, разделённых запятыми, соответствующий sites[].name.

Практика 5: граница между обновлением шаблона и кастомизацией

Do not edit this file directly! вверху всех .github/workflows/*.yml — не для пугания. update-template.yml каждую неделю будет перезаписывать эти файлы шаблоном upstream. Когда нужна кастомизация поведения, правильный подход — использовать официально поддерживаемые элементы конфигурации в .upptimerc.yml (например, skipTopics, customStatusWebsite, runnerSettings), а не изменять workflow. Если действительно нужно изменить workflow, либо отключите update-template.yml, либо форкните и поддерживайте шаблон самостоятельно — последнее лишит безболезненного обновления, взвешивайте得失.

Практика 6: реальные ограничения бесплатной квоты

GitHub Actions бесплатен для публичных репозиториев, без ограничения времени, и именно это использует дизайн Upptime. Для приватных репозиториев есть 2000 минут бесплатной квоты в месяц, а uptime.yml запускается каждые 5 минут, каждый раз около 1 минуты, только это одно за месяц составит примерно 8640 минут, что превысит квоту. Поэтому репозиторий Upptime должен быть публичным — это предпосылка слова “бесплатно” — не открывайте private ради секретности, а потом получите счёт — это будет неловко.

Резюме

Вернёмся к вопросу в начале: есть ли дешёвое решение для мониторинга кучи внешних сервисов? Ответ HagiCode — есть, и настолько дешёвое, что вы усомнитесь, правда ли это. Upptime разбивает мониторинг на четыре нативных компонента GitHub:

• зонд = cron в GitHub Actions
• база данных = файлы YAML/JSON в репозитории
• CDN = GitHub Pages
• журнал событий = GitHub Issues

Вы получаете: реальную доступность, кривые времени отклика, исторические события, значки доступности, кастомный домен, автоматические уведомления — всё с нулём серверов, нулём ежемесячных платежей. Цена — поддерживать репозиторий публичным и иногда заботиться о его объёме. На самом деле эта цена уже намного легче, чем ручное создание системы мониторинга.

Причина, по которой это решение работает, — искренняя субсидия экосистемы GitHub для open source проектов. Если вы тоже поддерживаете небольшую матрицу продуктов с несколькими сайтами, настоятельно рекомендуйте потратить полдня и развернуть это — намного проще, чем ручное создание мониторинга.

Ссылки

• Официальный репозиторий Upptime
• Документация по endpoint значкам shields.io
• Документация по запланированным задачам GitHub Actions
• Пример страницы состояния HagiCode

Заключение

Вокруг темы “как использовать Upptime для бесплатного создания собственной страницы состояния”, более надёжный подход — сначала пошагово отработать ключевые конфигурации, границы зависимостей и путь внедрения, а затем дополнять оптимизационные детали.

Когда цели, шаги и точки приёма чётко определены, такие решения обычно могут более плавно перейти к фактической доставке.

AI-перевод

Эта страница переведена с оригинала на упрощённом китайском языке с помощью ИИ.

Обратитесь к оригиналу, если нужно проверить формулировки, технические нюансы или последние обновления.

Открыть оригинал на упрощённом китайском

Tags:

• Upptime
• GitHub Actions
• мониторинг состояния
• страница состояния
• GitHub Pages
• HagiCode
• DevOps

Реализация интеграции с Pi Agent: разбор сообщений, повторы и отмена

Как опубликовать Electron-приложение в Microsoft Store: от создания пакета MSIX до отправки в магазин