Мониторинг Deno Deploy: edge-функции и health URL

В дашборде Deno Deploy всё зелёное, а пользователи в одном регионе ловят 5xx. Встроенные логи, трейсы и метрики смотрят трафик внутри платформы — не то, проходит ли синтетический GET с публичного интернета. Решение: /healthz и /readyz на production URL и регистрация того же HTTPS-адреса в StillOnline.

Краткий ответ

Observability Deno Deploy — телеметрия в дашборде, не внешний аптайм. StillOnline шлёт только HTTP GET и смотрит код ответа. Добавьте GET /healthz (liveness) и /readyz (readiness с 503 при сбое зависимостей). Free: один URL, ~5 мин, только код статуса.

Deno.serve крутит TypeScript на edge. Автотрейс HTTP полезен для отладки, но не заменяет расписание проб снаружи. База: мониторинг edge на Cloudflare Workers · быстрый старт health URL.

1. Что мониторить на Deno Deploy vs origin API

Три слоя: L1 edge URL (*.deno.net или свой домен), L2 зависимости (REST API, Deno KV), L3 Deno.cron. Метрики дашборда — L1 внутри Deno; они не делают curl на публичный URL из другого региона.

Шесть регионов Deno Deploy → асимметричные сбои. Каденция StillOnline ~5 мин подходит большинству indie SaaS.

Делайте: регистрируйте StillOnline на каноническом production URL. Не делайте: считайте вкладку Observability доказательством аптайма.

2. Публичный health URL для edge handlers

/healthz — liveness. /readyz — readiness. 503 при падении зависимости; Cache-Control: no-store; без auth.

if (url.pathname === "/healthz") return new Response("ok\n", { status: 200, headers });
if (url.pathname === "/readyz") {
  const ready = await pingOrigin();
  return new Response(ready ? "ready\n" : "down\n", { status: ready ? 200 : 503, headers });
}

1. Канонический хост — домен клиентов или production *.deno.net.
2. GET /healthz и /readyz на этом хосте.
3. Таймаут зависимостей в /readyz — 2–3 с.
4. curl снаружи до монитора.
5. 503, когда origin недоступен пользователям.

Не делайте: 200 с {"ok": false} на StillOnline Free — JSON не парсится.

Подробнее: дизайн health endpoint.

3. Deno.cron без ложных зелёных

Deno.cron — на верхнем уровне модуля до Deno.serve(). UTC, at-least-once.

Паттерн: cron пишет last_ok в KV каждые 5 мин; /readyz отдаёт 503, если метка старше 15 мин.

Не регистрируйте cron внутри request handlers — Deploy видит jobs только при деплое.

Отдельный origin: мониторинг API-only SaaS.

4. Подключение StillOnline и алерты

1. stillonline.tech/app → проект.
2. Проверка: GET https://your-app.deno.net/readyz, ожидание 200.
3. Компонент «Deno edge» на странице статуса.
4. Один канал алертов на Free.
5. Подождите 2–3 цикла (~10–15 мин).

При алерте: curl /readyz с домашней сети, Traces с 5xx, TLS домена, origin. StillOnline — два провала подряд → DOWN. Pro / Ultimate — больше URL и каналов (тарифы).

5. Чеклист перед launch week

1. Production с /healthz и /readyz.
2. TLS кастомного домена.
3. curl обоих path снаружи.
4. Сломайте origin — /readyz должен дать 503.
5. StillOnline на /readyz.
6. Тест канала алертов.
7. Runbook: метрики + curl + владелец origin.

Репетиция: /healthz = 200, origin сломан → /readyz = 503.

Что дальше

Задеплойте пробы, зарегистрируйте StillOnline на /readyz, добавьте cron→KV, если фоновые job'ы критичны.

Дашборд StillOnline — вставьте URL /readyz.

Связанные материалы

• Дизайн health endpoint
• Uptime на Cloudflare Workers
• Мониторинг API-only SaaS
• Быстрый старт health URL

FAQ

Deno Deploy vs Cloudflare Workers в StillOnline?

Оба требуют внешний GET. У Deno есть Deno.cron и OTEL; подключение StillOnline одинаковое.

Мониторить *.deno.net или свой домен?

Тот хост, который видят клиенты.

Почему метрики зелёные, а пользователи видят ошибки?

Региональная маршрутизация или origin. Внешний GET на /readyz + Traces.

StillOnline Free парсит JSON в health?

Нет — только код. 503 при сбое.

Deno.cron заменяет StillOnline?

Нет. Cron внутри платформы; StillOnline — внешний probe.

Что класть в /readyz — KV или origin?

Только то, без чего пользователь не работает, с коротким таймаутом.