Я вже два тижні в сабатикалі — перерва в ролі Engineering Manager в MacPaw. План був навмисно розмитий: ніякого чіткого маршруту, ніякого списку "як продуктивно провести сабатикал". Просто час подумати — і подекуди, час побудувати щось, про що ніхто не просив.
Це історія про одну з таких речей: InternetVitals — дашборд здоров'я ключової інтернет-інфраструктури в реальному часі, зроблений так, щоб виглядати і відчуватись як монітор пацієнта в реанімації.
Тригер
Думаю, більшість з нас переживали один і той самий момент: падає якийсь ключовий шматок інфраструктури — AWS us-east-1, Cloudflare, будь-хто цього разу — і раптом половина інтернету починає поводитись як таксі з пробігом 300 000 км, у якого тролить двигун. Технічно все ще їде. Нормально — ні.
Одного вечора впав Anthropic Claude. Дрібна незручність, переважно кумедна. І десь у тій дрібній незручності з'явилась ідея: а що якщо подивитись на Інтернет як на пацієнта в реанімації? Кожен ключовий сервіс — це орган. Деякі важливіші за інші. І замість стіни з зелено-жовто-червоних бейджів статусів — що якщо все це читати як вітальні показники: пульс, температура, тиск, сатурація?
Так з'явився InternetVitals: 41 ключовий сервіс — Cloudflare, AWS, Azure, GCP, GitHub, Stripe, основні DNS-провайдери та інші — зведені в один зважений Health Score, плюс чотири похідні "вітальні показники", які мапують ті самі дані на медичну метафору.
Це не стартап
Варто сказати прямо: бізнес-моделі тут немає. StatusGator, Downdetector та кілька інших вже добре роблять "чи впав інтернет", і в них є реальна дистрибуція. Я не намагаюсь з ними конкурувати. Це фановий проєкт — побудований тому, що ідея мене насмішила, і тому, що захотілось подивитись, наскільки далеко можна довести цей жарт, якщо побудувати все по-справжньому.
Зайшло доволі далеко. Тепер є тема "Console" — чорний фон, зелений моноширинний текст, ASCII-прогресбари і живий tail -f /var/log/vitals.log з реальними інцидентами в стилі syslog. Здебільшого easter egg для тих, хто любить термінали, але саме ця частина в результаті стала моєю улюбленою.
Що саме вимірюється
Кожен сервіс отримує вагу залежно від оціночної частки в глобальному інтернет-трафіку і того, наскільки все зламається, якщо він впаде. Наприклад, CDN-шар Cloudflare має набагато більшу вагу, ніж статус-сторінка дрібного SaaS — втрата Cloudflare має зовсім інший радіус ураження, ніж втрата, скажімо, Okta.
Чотири вітальні показники — похідні від тих самих даних перевірок, просто виражені по-різному:
- Пульс (BPM) — зростає з кількістю активних інцидентів
- Температура (°C) — зростає зі зниженням загального Health Score, як справжня лихоманка
- Тиск — систолічний від здоров'я CDN-шару, діастолічний від здоров'я DNS-шару
- SpO2 — сатурація резервування ключової інфраструктури
Нічого з цього не претендує на наукову точність. Це метафора з формулою за нею, а не дослідницька стаття. Але вона робить дашборд читабельним так, як ніколи не зробив би простий список з 41 статус-бейджа.
Стек — повністю Cloudflare, без жодного сервера
Весь проєкт працює виключно на інфраструктурі Cloudflare, що здалось доречним зважаючи на тему:
- Workers (TypeScript, Hono.js) — рантайм для всього
- Cron Triggers — спрацьовують кожні 5 хвилин, перевіряючи всі 41 сервіс паралельними батчами
- D1 (SQLite) — зберігає історію перевірок і розрахованих вітальних показників у часі
- KV — кешує поточний стан, щоб фронтенд отримував миттєву відповідь замість того, щоб щоразу йти в D1
- Pages — віддає статичний фронтенд, vanilla JS, без фреймворку
Більшість великих сервісів використовують statuspage.io JSON API, що робить їхню перевірку тривіальною — один уніфікований формат. Винятки (AWS, Azure, GCP, Apple) не мають чистого публічного API, тому довелось писати окремі парсери: парсити HTML інцидентів, парсити RSS-фід, розпаковувати JSONP-відповідь. Не дуже елегантно, але працює.
Як це насправді будувалось
Ось частина, яка цікавить мене більше за сам продукт: на все пішло близько 8 годин за два вечори, і в код я майже не заходив руками.
- Концепція, в чаті. Я проговорив ідею з Claude — медичну метафору, назву домену, які сервіси важливі і як приблизно їх зважити. Мета на цьому етапі — швидкість, не точність.
- PRD. З тієї розмови ми побудували повноцінний документ вимог — структуру файлів, схему бази даних, API-контракт, конфігурацію
wrangler.toml— все, що потрібно Claude Code для реалізації без необхідності уточнювати кожну деталь по ходу. - Дизайн. Claude Design зайняв кілька ітерацій — приблизно чотири — перш ніж дійшов до того вигляду "ICU monitor", який був у мене в голові. Виявляється, мій смак конкретніший, ніж я думав.
- Реалізація. Маючи на руках дизайн і PRD, Claude Code зробив основну частину реальної розробки — чекери, cron-логіку, фронтенд. Моя роль звузилась до рев'ю, дрібних правок і деплою.
Навіщо будувати це в сабатикалі
Підозрюю, дехто прочитає це і подумає: хіба сенс сабатикалу не в тому, щоб відійти від того, чим займаєшся на роботі? Справедливо. Але для мене такий тип будування — це інша категорія роботи, ніж моя основна. Без дедлайнів, без команди, яка чекає рішення, без роадмапу — просто ідея, вечір і можливість дійти від напівоформленого жарту до живого продукту до того, як піти спати. Це відновлює, навіть якщо ззовні виглядає точнісінько як робота.
Справжній висновок
Дашборд — це не зовсім суть. Суть — у часі побудови. Вісім годин, два вечори, нуль рядків коду, написаних мною з нуля. Той розрив — між "у мене є ідея" і "воно вже працює" — стиснувся драматично, і думаю, більшість людей ще не до кінця це усвідомили.
Якщо у вас є трохи абсурдна ідея, яку ви відкладали, бо здавалось, що це забагато зусиль для пет-проєкту — ймовірно, це вже не так.
Подивитись на поточні вітальні показники Інтернету можна тут: internetvitals.com.