Что нового

Сводка по релизам — что изменилось и зачем. Полный технический список — в CHANGELOG, анонсы — в Telegram-канале.

1.9.0 · 28 сентября 2026 — установщик больше не трогает веб-сервер и TLS

Ломающий релиз для установки без Docker: установщик перестал ставить и настраивать веб-сервер и сертификаты. Gotcha слушает только 127.0.0.1:8080, а каким прокси выводить его наружу — решаете вы. Одно исправление касается всех установок, включая Docker: запросы к PostgreSQL под нагрузкой на CPU могли падать с i/o timeout. Миграций нет.

• nginx, certbot, EPEL, SELinux-boolean и firewalld из установщика ушли. Вместо них в документации — раздел «Внешний доступ и TLS»: шесть требований к любому обратному прокси и проверенные примеры для nginx, angie, Apache и Caddy. Флаги --domain и --email теперь отказывают с кодом 2 и подсказкой, а --no-proxy и --no-firewall принимаются и ничего не делают — старые скрипты автоматизации на них не споткнутся.
• --base-url обязателен при чистой установке. Внешний адрес должен в точности совпадать с GOTCHA_BASE_URL, иначе любой POST, включая первую регистрацию, получает 403 — поэтому угадывать его установщик больше не пытается. Без флага он спросит адрес в терминале, а с --yes или без терминала откажет до любых изменений на хосте. Повторный запуск с другим --base-url переписывает адрес в /etc/gotcha/gotcha.env, не трогая паролей и ключа, и перезапускает сервис.
• Обновление с 1.8.x: уберите из команды --domain и --email. Сайт nginx и сертификат, которые поставила прошлая версия, остаются на месте и дальше обслуживаются вами.
• Лимит попыток входа за прокси был общим на всех. Когда обратный прокси стоит на том же хосте, каждый запрос выглядел пришедшим с 127.0.0.1: установщик не прописывал GOTCHA_TRUSTED_PROXIES. Теперь он пишет GOTCHA_TRUSTED_PROXIES=127.0.0.1/32,::1/128 при установке и добавляет в существующий env при повторном запуске; значение, заданное оператором, не трогает.
• i/o timeout к PostgreSQL под нагрузкой — исправлено. Проверка соединения перед выдачей из пула, появившаяся в 1.8.1, ждала ответа всего 50 мс. Под нагрузкой на CPU этого не хватало даже живому соединению, и следующий запрос по нему падал с i/o timeout. Таймаут поднят до секунды: он по-прежнему отсекает зависшее соединение, но не трогает живое.
• Установщик доставляет недостающее сам. Базовые утилиты вроде tar, curl и runuser он ставит, а не обрывает установку, и в конце печатает итог: версию, ответ /readyz, адрес и что осталось сделать.

1.8.1 · 22 сентября 2026 — установка без Docker на AlmaLinux, Rocky и RHEL

Второе семейство дистрибутивов для установки без Docker — и одно исправление, которое касается всех установок, включая работающие в Docker: пул соединений мог выдать приложению соединение, уже закрытое со стороны PostgreSQL. Версия 1.8.0 была затегирована, но не опубликована: установщик в ней не работал на AlmaLinux/Rocky/RHEL 9 и ни на одном хосте arm64 этого семейства, поэтому всё её содержимое вошло в 1.8.1. Миграций и новых переменных окружения нет.

• AlmaLinux, Rocky Linux, RHEL 9 и 10 — amd64 и arm64. install-bare-metal.sh и зеркальные ему ручные шаги теперь работают на втором семействе дистрибутивов наравне с Debian и Ubuntu. Два отказа, на которых установка обрывалась, устранены: sudo: PAM account management error при первом же обращении к PostgreSQL и падение на подключении репозитория PGDG на arm64 — метаданные для aarch64 PostgreSQL подписывает отдельным ключом, а установщик импортировал ключ x86_64. Ключ теперь выбирается по архитектуре хоста.
• 500 сразу после рестарта PostgreSQL — исправлено. Запрос, пришедший в первые мгновения после перезапуска базы, мог упасть с 500, хотя /readyz в это время отвечал, что база готова: пул отдавал соединение, которое сервер уже закрыл. Теперь пул проверяет соединение перед выдачей и прозрачно заменяет протухшее. Это единственный пункт релиза, который касается и тех, кто ничего не устанавливает заново.
• runuser вместо sudo. Команды от имени пользователя postgres выполняются через runuser: sudo проходит полный стек PAM, account-фаза которого сразу после создания системного пользователя может ещё ждать NSS. Для установки теперь нужен не sudo, а runuser из пакета util-linux — на Debian, Ubuntu и EL 9 он стоит по умолчанию, а на RHEL 10 и его пересборках ставится только util-linux-core, и полный пакет нужно доставить. Preflight сообщает о нехватке так же, как о любой другой отсутствующей команде.
• Установщик больше не молчит про firewalld и SELinux. На AlmaLinux/Rocky/RHEL он выставляет SELinux-boolean httpd_can_network_connect и открывает порты 80/443 в firewalld, а когда пропускает это — говорит почему: отдельное предупреждение, если firewalld не найден или не запущен, отдельное сообщение с готовой командой, если оператор сам отказался на интерактивном вопросе, и тишина при новом флаге --no-firewall, потому что это осознанный выбор. Ни SELinux-boolean, ни открытые порты --uninstall не отменяет.
• Отказ certbot не обрывает установку. На обоих семействах дистрибутивов HTTP-стенд на 80 порту остаётся рабочим, а сертификат можно допровести позже той же командой.

1.6.1–1.7.1 · 17–18 сентября 2026 — установка без Docker и число за словами «небольшая нагрузка»

Три релиза подряд про то, как Gotcha попадает на сервер и что о нём написано до установки. Появился второй способ поставить продукт — на чистый Debian или Ubuntu, без Docker; требования к железу пересняты на текущем релизе, потому что прежние снимались, когда в продукте ещё не было ни логов, ни метрик хостов; а страница ручной установки перестала обрываться на вопросе, который задаёт установщик пакета. Ни одной миграции, ни одной новой переменной окружения — для тех, кто уже работает в Docker, не меняется ничего.

• Установка без Docker (1.7.0). install-bare-metal.sh со страницы релиза ставит PostgreSQL, ClickHouse и само приложение как systemd-сервис на чистый хост Debian или Ubuntu. Рядом — страница документации с теми же шагами руками, для тех, кому чужой скрипт в проде не подходит: видно каждую команду и каждый файл конфигурации, который она пишет. В релизах появились бинарные тарболы под каждую архитектуру, а к HTML-документации добавился PDF-комплект эксплуатационных страниц — установка, конфигурация, hardening, бэкап и восстановление, обновление — на каждую локаль: это то, что нужно читать тогда, когда до самого сервиса ещё или уже не достучаться.
• Ручная установка больше не обрывается на вопросе установщика (1.7.1). На живом терминале постинстал clickhouse-server спрашивает пароль для пользователя default, и любой заданный там пароль ронял следующий же шаг документации — создание базы — с ошибкой 516 AUTHENTICATION_FAILED. Страница теперь ставит пакеты неинтерактивно, как это давно делает скрипт-инсталлер. Сгенерированный пароль пользователя gotcha в ClickHouse печатается там же, где создаётся: в конфиге хранится только его SHA-256, и восстановить пароль потом неоткуда. В «Типичных ошибках» разобраны оба отказа аутентификации и описан выпуск нового пароля, а сам инсталлер, не сумев создать базу, теперь называет вероятную причину вместо голого кода ошибки.
• «Небольшая нагрузка» стала числом (1.6.1). Требования к железу и замеры оверлея для слабого железа снимались на ранней версии — тогда в продукте не было ни приёма логов, ни метрик хостов, и цифры описывали уже не тот продукт, который вы ставите. Теперь названо, на каком потоке проверен минимум в 2 ГБ: 10 000 событий, 200 000 строк логов и 5 000 трейсов в сутки, четыре часа непрерывной нагрузки без отказов приёма. Рядом — память каждого из трёх контейнеров и доля диска, которую занимают сами данные.

1.5.2–1.6.0 · 16–17 сентября 2026 — дешёвые пробы здоровья и правда в документации

Три небольших релиза после сентябрьской волны: пробы здоровья перестали ходить в базы на каждый запрос, документация установки договорила недосказанное, а подсказка про эскалации перестала утверждать неверное. Ни одной миграции, ни одной новой переменной окружения — обновление сводится к замене образа.

• /healthz и /readyz больше не пингуют базы на каждый запрос (1.6.0). Обе ручки делят один замер, результат которого переиспользуется до пяти секунд. Раньше каждый запрос к любой из них стоил двух походов в PostgreSQL и ClickHouse — а пробу обычно дёргают сразу с трёх сторон: балансировщик, readiness-проба оркестратора и healthcheck контейнера. Заметная доля небольшого общего пула соединений уходила на запросы, которые даже не требуют аутентификации. В теле ответа появилось поле checked_at — время фактического замера в формате RFC3339, по нему видно, насколько свежее состояние вы читаете. Коды ответов и смысл обеих ручек не изменились.
• Подсказка про эскалации говорила неправду — проверьте свои лестницы. Панель помощи утверждала, что последующие ступени лестницы расширяют круг получателей. Это не так: у каждой ступени свой набор каналов, никак не связанный с предыдущей, и ступень, где не отмечен ни один канал, не уведомит никого — даже если на первой ступени каналы отмечены. Если вы настраивали эскалации, полагаясь на эту фразу, на верхних ступенях может не оказаться ни одного получателя. Текст исправлен, заодно переписаны подсказки подавления шторма.
• Документация установки договорила недосказанное (1.5.2, 1.5.3). Сколько диска нужно сборке из исходников сверх рабочего набора, с фактическими размерами образов, и как освободить кэш сборки после неё. Новый случай в устранении неполадок: ClickHouse не проходит проверку здоровья, и приложение из-за этого не стартует — проверять в первую очередь память и диск, потому что при нехватке памяти ядро снимает процесс и в логе самого ClickHouse может не остаться ничего внятного. Раздел про operation not permitted теперь говорит, что делать, если обе пробы прошли: дефект был в образе, и пересборка начисто его снимает. И названа версия Go, на которой собирается образ, — рядом с версиями PostgreSQL и ClickHouse, которые там уже были.
• Под капотом: документация больше не может тихо разойтись с кодом. Появились тесты, которые падают на расхождении: версии Go, PostgreSQL и ClickHouse в документации сверяются с кодом, имена таблиц — с миграциями, роли в организации — с типом и схемой, адреса приёма телеметрии — с фактическими маршрутами, время жизни кэша проб здоровья — с кодом. Отдельный сторож ловит ключи перевода, на которые уже никто не ссылается. Из интерфейса этого не видно, но именно оно отвечает за то, что в документации написана правда, а не то, что было правдой полгода назад.

1.4.0–1.5.1 · 14–15 сентября 2026 — волна корректности и безопасности

Четыре релиза за двое суток, собранные в одну запись: полный аудит кодовой базы 1.x и его устранение (1.4.0), починка ошибки, которую привезла сама эта волна (1.4.1), ещё две закрытые находки (1.5.0) и редкий отказ приёма, доведённый до корня (1.5.1). Контракт 1.0 не нарушен: ни одна переменная окружения не переименована, адреса приёма и форматы тел запросов не менялись, пять новых миграций (0094–0098) идут только вперёд. Четыре новые переменные окружения сохраняют прежнее поведение по умолчанию.

Если вы на любой 1.x — обновляйтесь сразу на 1.5.1. На 1.4.0 останавливаться не нужно: сутки он отдавал каждую страницу больше килобайта как файл на скачивание — сжатие уехало с неверным типом содержимого, 1.4.1 починил.

• Две вещи меняются на существующей установке, обе про вход. Вход через единый вход организации больше не привязывается молча к существующему парольному аккаунту по совпадению адреса: любой, кто стал владельцем адреса в домене организации — заново созданный ящик или переданный после ухода прежнего сотрудника, — мог войти как владелец существующего аккаунта, никогда не зная его пароля. Привязка стала осознанным действием владельца аккаунта из своего профиля, поэтому тот, кто раньше входил одним щелчком, один раз войдёт паролем и привяжет единый вход руками. Отдельно: саморегистрация и привязка по адресу через произвольного OIDC-издателя теперь требуют GOTCHA_OIDC_TRUST_EMAIL=true — такой издатель может проставить email_verified сам, поэтому доверять ему стоит только если это ваш собственный однотенантный IdP. Yandex ID и VK ID не затронуты: они подтверждают адрес сами.
• Проверьте, работал ли инстанс когда-нибудь без GOTCHA_SECRET_KEY. Всё зашифрованное с тех пор записано под ключом разработки — токены каналов оповещений, клиентские секреты единого входа, заголовки HTTP-мониторов. Перешифровать после установки ключа недостаточно: открытый текст уже попал в журнал упреждающей записи и в резервные копии, поэтому такие секреты нужно отозвать и выпустить заново. Раньше признак был виден только строкой в логе старта, которая не переживает ротацию логов контейнера; теперь это метрика gotcha_secret_key_insecure на /metrics и предупреждение прямо на форме, куда такой секрет вводят.
• Разбор профилей ограничен по памяти. Подготовленный профиль мог раздуть несколько килобайт входа в гигабайты кучи: теперь разбор идёт под фиксированным бюджетом, делает один линейный проход по входу перед декодированием и применяет отдельный байтовый потолок к входу, форма которого не подтверждена как protobuf. Число одновременных разборов стало бюджетом памяти, а не счётчиком штук.
• Приём ограничивает частоту по адресу клиента до проверки ключа. Поток запросов со случайными ключами доходил до кэша ключей и до базы с её небольшим общим пулом соединений, прежде чем быть отвергнутым. Сигнал «неверный ключ» к тому же записывался на тот id проекта, что стоял в URL и проверялся раньше самого ключа, — перебор id мог показать владельцу тревогу о попытке, которая к нему не относилась. Заодно: лимитер с переполненной картой ключей отказывал всем подряд, включая непричастных, пока записи не истекут — ровно тот исход, который он должен предотвращать.
• Значение метрики на краю диапазона float64 могло навсегда завесить обработчик, рисующий её график, сжигая ядро на каждую открытую страницу до перезапуска; значение у противоположного края рисовало все точки на нуле с подписями «Infinity». Приём, доступный публичным ключом проекта, теперь такие значения отвергает. Журнал доставки больше не показывает полный текст ошибки тем, у кого нет прав управлять каналами, а приглашения в организацию ограничены по частоте: без предела администратор мог рассылать почту инстанса на любые внешние адреса.
• Вычислители под нагрузкой молча делали часть работы — теперь продолжают с места обрыва. Вычислители хостов, правил метрик и SLO и планировщик эскалаций начинали свой список заново каждый тик: всё, что не влезало в бюджет тика, не проверялось вообще никогда, а в шторме инцидентов планировщик снова и снова эскалировал одни и те же самые старые, пока новые ждали бесконечно. Сколько пропущено в последнем тике, теперь видно метрикой. Рядом закрыты соседние промахи: окно SLO без единого результата проверки больше не считается здоровым (замолчавший монитор мог закрыть инцидент прогорания и разослать «SLO восстановился»), регрессия, чья цель ушла из выборки трафика, больше не остаётся открытой вечно, а инцидент по пропущенной проверке не открывается дважды, когда промах видят две реплики.
• Квота больше не списывается до разбора тела. Битый или слишком большой запрос стоил квоты, не приняв ничего, а конверт из одних профилей на инстансе с выключенным приёмом профилей отвечал 200 и пропадал бесследно. Писатели метрик и профилей теперь считают отброшенные при переполнении буфера строки и возвращают списанную за них квоту — тот же учёт, который уже был у событий и транзакций, стал общим для всех четырёх. Идентификатор трассы клиент задаёт целиком, поэтому два проекта могут прислать один и тот же: разрешение стало детерминированным, и проект, скопировавший чужой идентификатор, больше не затеняет чужую трассу.
• Редкий отказ ClickHouse при одновременных записях доведён до корня. use of closed network connection возникал так: на отмене контекста батча клиент рвёт сокет напрямую, минуя пул, — а соединение к этому моменту уже вернулось в пул и могло принадлежать постороннему запросу, который и падал. Контекст сброса у писателей больше не отменяемый, а бюджет сброса держат таймауты отдельного писательского соединения.
• Что появилось в 1.4.0. Страница /forgot-password: одноразовая ссылка на час на адрес аккаунта, установка нового пароля завершает все его сессии, свой лимит частоты, ответ не выдаёт, существует ли адрес, а на инстансе без SMTP страница честно об этом говорит вместо формы, которая ничего не сделает. Оператору — gotcha set-password --email=<адрес>, читающий пароль со стандартного ввода, поэтому он не попадает ни в историю оболочки, ни в список процессов. Агрегация increase для правил по монотонным счётчикам: порог «10 ошибок за 5 минут» теперь означает именно это и не зависит от того, как часто снимают метрику, а сброс счётчика при перезапуске экспортёра больше не выглядит всплеском размером во всё накопленное. Реально применённый срок хранения каждого набора данных ClickHouse пишется в лог на старте и отдаётся метрикой gotcha_retention_days{dataset="…"}. Адрес публичной страницы статуса можно сменить, не удаляя её вместе с мониторами и историей. GOTCHA_SMTP_REQUIRE_TLS отказывается отправлять письмо, если сервер не предложил STARTTLS, вместо отката на открытое соединение.
• Страницы отдаются сжатыми, а вычислитель хостов перестал спрашивать базу по разу на хост. Через компрессор идёт только разметка: выгрузки и раздача бинарей агента проходят мимо нетронутыми, поэтому докачка и диапазонные запросы работают как раньше. Вычислитель хостов теперь делает один сгруппированный запрос на проект и вид порога — хост не входит в ключ сортировки таблицы, поэтому пятьсот хостов означали пятьсот запросов, каждый из которых вычитывал окно всего проекта. По живому журналу запросов на пятистах хостах: 500 запросов и 750 000 прочитанных строк стали 1 запросом и 1 500 строк.
• Руководства сверены с кодом, а не с памятью, и расхождения были не косметические. Руководство по хостам дважды отправляло читателя за ключом, которым метрики пишутся, а хост зарегистрировать нельзя; руководство по самомониторингу предлагало алерт на метрику, которой в продукте нет; пример SMTP использовал порт 465, на котором этот клиент не умеет говорить вовсе, так что почта просто висела до таймаута. Справочник событий вебхука описывал 8 видов из 23 — теперь описаны все 23, и сторож не даёт списку снова разойтись с кодом. И два ограничения, на которых люди спотыкались, наконец записаны: отзыв ключа приёма вступает в силу секунд через тридцать, потому что разрешение ключей кэшируется, а «завершить все сессии» никогда не умела завершать чужую.
• Отзыв одного диагноза. 1.3.1 объяснял exec /usr/local/bin/gotcha: operation not permitted докером, поставленным из snap. Объяснение уехало на косвенных уликах, и прямая контрпроба его не подтвердила: на хосте, где симптом воспроизводится, контейнер с no-new-privileges поднимается нормально. Раздел «Устранение неполадок» больше не называет причину — он даёт две проверки, разделяющие «ограничения контейнера отвергнуты» и «сломан образ или бинарь».

1.1.0–1.3.1 · 8–11 сентября 2026 — приём перестал отвечать «принято» на то, что мог потерять

Четыре релиза после 1.0, и три из них существуют потому, что читатель завёл issue и оказался прав. Обещание 1.0 при этом не нарушено ни разу: ни одна переменная окружения не переименована, адреса приёма и форматы тел запросов не менялись, обе новые миграции идут только вперёд — обновление с 1.0 всё так же сводится к «прочитать Обновление, подтянуть образ, поехали».

• Переполненный буфер теперь отвечает 503, а не 200 (1.2.0). До этого релиза приём ставил запись в очередь и отвечал успехом безусловно, а сама постановка могла элемент выбросить: закрытый конвейер, полная очередь, исчерпанный байтовый бюджет. Следующий буфер перед ClickHouse — тоже в оперативной памяти — при переполнении вытесняет самое старое. Клиент видел успех, прекращал ретраи, данных не было. Теперь перед постановкой в очередь проверяется каждый буфер на пути сигнала, и если хоть один заполнен на 95% и выше — то есть принять ещё значит вытеснить более старое, — весь запрос отклоняется с 503 и Retry-After: 5, не приняв из него ничего. Проверка стоит до постановки в очередь и до списания квоты намеренно: повтор не создаёт дублей и не сжигает месячный лимит организации. Отказы считаются в gotcha_ingest_rejected_total{reason="overloaded"}.
• Запрос, из которого не встало в очередь ничего, тоже отвечает 503 (1.3.0). Проверка 1.2.0 оставляла гонку: элемент, выброшенный уже после неё, всё равно получал успех. Теперь постановка в очередь сообщает свой исход, и запрос, не положивший в очередь ни одного элемента, отклоняется — повторять его безопасно. Частично принятый конверт по-прежнему отвечает 200: его повтор задвоил бы прошедшую часть, а дедупликации по идентификатору события в продукте нет.
• Воркер ждёт место вместо того, чтобы вытеснять обещанные данные (1.3.0). Перед записью в насыщенный батчер или писатель спанов воркер приёма теперь ждёт до двух секунд, опрашивая каждые 50 мс. Видно это по двум новым self-метрикам: gotcha_pipeline_backpressure_waits_total и gotcha_pipeline_backpressure_wait_seconds_total. Если бюджет ожидания вышел, вытеснение самого старого всё-таки срабатывает — осознанно: в мониторинге свежие данные дороже протухших.
• Ретраи больше не жгут квоту (1.3.0). Списание шло до постановки в очередь, а отказ решался после, поэтому клиент, добросовестно повторявший наш же 503, платил за каждую попытку. Теперь квота списывается только за то, что реально встало в очередь, а списанное за отклонённое по нехватке ёмкости возвращается. За битый payload не возвращается никогда: квота здесь работает ещё и ограничителем злоупотребления, и бесплатный мусор сделал бы поток мусора бесплатным.
• Профили больше не умирают под чужой квотой (1.3.0). Решение по профилям принималось после событий и транзакций, так что исчерпанные квоты этих двух роняли профили молча, под ответом 200. Теперь профиль — полноправный класс конверта и в правилах, и в квоте, и в перегрузке. Видимое следствие: конверт из одних профилей при исчерпанной квоте профилей отвечает 429.
• Логи можно вычитать, а не только сужать (1.1.0). У фильтров логов были только положительные условия: сузить до чего-то — можно, убрать что-то — нельзя. А убрать обычно хочется именно то, что легко назвать: повторяющееся предупреждение nginx, строку health-check, один болтливый сервис. Теперь у каждого значения фасета — уровня, сервиса, окружения, атрибута — есть чип исключения, и у текста тела записи есть своё исключение подстроки. Фильтры сохраняются — лично или на весь проект, — и один сохранённый фильтр в проекте можно назначить умолчанием: он применяется при чистом заходе в раздел логов, а ссылка «показать всё» снимает его на текущий просмотр, так что умолчание не может спрятать данные от того, кто его не ставил.
• Выключатель no-new-privileges для хостов, где с ним не стартовать (1.3.1). Контейнер приложения падал на exec с operation not permitted, не напечатав ни строки лога, ровно на одной конфигурации: Docker, установленный из snap, где сам dockerd работает под профилем AppArmor и ядро отказывает контейнеру в переходе в свой профиль. Симптом теперь назван в «Устранении неполадок» установки прямо, вместе с проверкой в одну строку вообще без Gotcha. Настоящее лечение — Docker не из snap; GOTCHA_COMPOSE_NO_NEW_PRIVS снимает флаг как временная мера и по умолчанию остаётся включённым.
• Что осталось незакрытым и почему. Потеря при жёстком убийстве процесса до флаша никуда не делась: штатное выключение дренирует буферы (stop_grace_period: 90s и параллельный дренаж), а настоящий крах требует журнала на диске, и в ветке 1.x его не будет. Поэтому контракт приёма теперь записан в документации словами: 2xx означает «принято в память, записано асинхронно после этого», а не «сохранено».

0.36.0–1.0.0 · 5–6 сентября 2026 — первый стабильный релиз

Четыре релиза, и главный из них — 1.0. Важно в этом номере не то, сколько приехало за два месяца с первого тега 0.1.0 от 22 июля, а то, чего у 0.x не было вовсе: письменное обещание совместимости.

• 1.0: контракт совместимости заморожен (1.0.0). С этого релиза только назад совместимо меняются: имена переменных окружения, адреса приёма и форматы тел запросов, схема миграций, формат бэкапов, имена self-метрик без пометки «временная», тело исходящего вебхука, контракт GOTCHA_AGENT_* и адреса уже опубликованных статус-страниц. Всё, что это нарушает, ждёт мажорной версии. До 1.0 контракт мог меняться между релизами, и об этом говорилось прямо; больше не может. Что в обещание намеренно не входит — внутренние пакеты, внешний вид интерфейса, имена счётчиков с пометкой «временный», — сказано там же, вместе со сроками депрекации по каждому пункту: Политика версионирования. Практический смысл для того, кто держит инстанс: обновление перестаёт быть событием, к которому готовятся — прочитать Обновление, подтянуть образ, поехали.
• Страница проектов организации больше не показывает чужие проекты (1.0.0). В предикате доступа сработал приоритет операторов — AND связывает сильнее OR, — из-за чего ветвь «доступ через команду» оставалась без сужения по организации: тот, кто состоит в команде в другой организации, видел на /orgs/{id}/projects и её проекты. Права при этом не расширялись — каждый показанный проект пользователь и так мог открыть. Предикат заключён в скобки в самом объявлении, что защищает и два других запроса, которые из него собираются.
• Три устаревших адреса приёма удаляются в 2.0, а не в 1.0 (0.37.0). /logs, /profiles/pprof и /api/{project}/deployments/ продолжают работать: те же заголовки, тот же счётчик, те же ответы — изменился только документированный срок удаления. Причина — собственная политика депрекации: между объявлением об устаревании и удалением обязан пройти минимум один мажорный релиз, а устаревшими их объявили 31 августа. Ломать чужие интеграции релизом, который называется «обещание стабильности», было бы странно.
• Экран «Обзор» получил страницу документации (0.37.0). /docs/overview в обеих локалях: что именно считает каждая из трёх плиток состояния и за какое окно, на что влияет и на что не влияет переключатель 24 ч / 7 дн, чем наполняются и чем ограничены три секции ленты, когда показывается пустое состояние. Экран служит точкой входа в проект с 0.29.0, но своей страницы не имел.
• Откат бинаря на базу с более новой схемой больше не уходит в краш-луп (0.36.0). При старте показывается подготовленная ошибка гейта схемы — в том числе при включённой автомиграции, которая стоит по умолчанию: проверка опережения схемы теперь идёт до стадии миграции, а не только после неё. Это один из пяти блокеров, найденных репетицией обновления на копии продовых данных — апгрейд и откат проехали руками до релиза, а не после.
• Обновление зависимостей (0.37.1). golang.org/x/crypto поднят до v0.56.0 — закрыты GO-2026-6354 и GO-2026-6355, две адвизори об отказе в обслуживании в пакете SSH. Поставляемый бинарь им подвержен не был: единственный путь до этого кода — тестовая обвязка, а сам Gotcha никакого SSH не обслуживает. Вместе с ним до v0.41.0 поднят golang.org/x/text.

0.32.0–0.35.0 · 2–5 сентября 2026 — переименование переменных окружения и надёжность

Четыре релиза, из которых один ломающий: перед обновлением с 0.31.0 и ниже нужно поправить .env. Остальное — направление данных на карте зависимостей, правка правил без удаления и большой проход по надёжности эскалаций и выгрузок.

• Ломающее: 31 переменная окружения переименована (0.34.0). Перед заморозкой контракта 1.0 переименованы 17 серверных переменных, 3 переменные агента и 11 переменных Docker Compose и сборки. Старые имена больше не читаются: непустое значение под старым именем останавливает запуск и называет новое имя — вместо того чтобы молча применить умолчание. У агента сменился и тип: интервал сбора теперь целое число секунд (10–300), а не строка вида «30s». Полные таблицы соответствия — в CHANGELOG и на странице Обновление. Отдельно: GOTCHA_SECRET_KEY теперь обрезается по краям от пробелов. Если ключ когда-то скопировали с хвостовым пробелом, после обновления перестанет расшифровываться всё, что зашифровано на нём (секреты каналов доставки, секреты SSO) — молча, без ошибки при старте. Путь восстановления — через GOTCHA_SECRET_KEY_PREV, который читается ровно как задан; порядок описан на странице Обновление.
• Ломающее: молчаливые ошибки конфигурации теперь останавливают старт (0.34.0). Незнакомая переменная GOTCHA_* в окружении больше не игнорируется — запуск прекращается с подсказкой ближайшего известного имени (опечатка GOTCHA_HSTS_ENABLE без D раньше тихо применяла умолчание). Туда же: испорченный булев (GOTCHA_SCRUB_IP=ture), нераспознанный уровень или формат логирования, GOTCHA_SMTP_PORT вне диапазона, нулевые и отрицательные лимиты буферов, невалидные лимиты выгрузок, DSN с опечаткой (строка разбирается на старте, без подключения) и значение из одних пробелов. Инстанс, который уже работал со сломанным лимитом выгрузки, после обновления не поднимется, пока значение не исправят.
• Направление данных на карте зависимостей (0.32.0). У каждой зависимости на карте и в таблице теперь видно направление: ← сервис читает, → пишет, ⇄ и то и другое. Направление выводится из глагола операции в спанах (SELECT/INSERT, GET/SET). Раскладка перестроена — хранилища слева, HTTP-зависимости справа, сервис в центре, метрики (вызовы, p95, доля ошибок) на самих узлах; карта вмещает до 16 зависимостей вместо 8.
• Правила правятся, а не пересоздаются (0.33.0). Правило метрик и ребро подавления можно отредактировать и выключить, не удаляя. Выключение правила метрик закрывает его открытый инцидент — раньше такой инцидент висел вечно, а лестница эскалаций продолжала слать ступени. Пороги хостов и правила подавления редактируются в модальных окнах, ступени эскалации разложены сеткой — на широком экране вся лестница видна целиком.
• Страница heartbeat-монитора перестала притворяться опросной (0.33.0). График фаз DNS/TCP/TLS/TTFB и таблица последних проверок убраны — heartbeat ничего не опрашивает; вместо плиток аптайма показаны последний сигнал, льготный период и время, к которому ждут следующий. Плитка SSL осталась только у HTTP-мониторов, заголовок графика задержек следует выбранному периоду.
• Ключи и секреты в интерфейсе (0.33.0, 0.35.0). Вебхуки в списках каналов больше не печатают секретный путь целиком: хост и словарные сегменты читаются, токен замаскирован. Блок ключей DSN перестроен в карточки, тип нового ключа выбирается сегментированным переключателем. Предупреждение «нет активного ключа» теперь появляется и когда все ключи отозваны, а не только когда их нет вовсе. На странице проекта видно, что отправитель ещё использует устаревший адрес приёма, а отказы ключей за последний час (невалидный, отозванный, чужой проект, неверный тип) показаны прямо в пустом списке ошибок и в чек-листе подключения.
• Эскалации, окна обслуживания и выгрузки (0.35.0). Ступень эскалации на двух репликах могла уйти дважды — канал теперь занимает ступень до отправки, а не после. Инцидент, подавленный из-за упавшей зависимости, возобновляет эскалацию после её восстановления, а не молчит навсегда. Напоминания по инциденту доступности замолкают, если окно обслуживания началось уже после открытия инцидента, и возобновляются после него; пауза монитора глушит напоминания и лестницу, не закрывая инцидент. Выгрузка ошибок маскирует почту исполнителя по умолчанию, обрезание выгрузки отбрасывает наименее активные группы, а не произвольные.
• Точки метрик из будущего (0.35.0). Точка с временем впереди часов сервера приводится к моменту приёма — раньше она принималась как есть (в пределах суток) или отбрасывалась, и хост с убежавшими часами был для графиков и порогов невидим. Расхождение стало видимым: счётчик gotcha_metric_points_clock_skew_total и предупреждение с именем хоста. Гистограммы больше 512 корзин обрезаются согласованно, перцентили по гистограммам с отрицательными границами больше не падают в ноль.
• Приватность и доступ (0.35.0). Ссылки «войти» и «создать аккаунт» на странице приглашения больше не несут токен приглашения в параметре адреса, где он оседал в истории браузера, логах обратного прокси и заголовках исходящих запросов — токен переехал в короткоживущую cookie. Удаление данных субъекта теперь стирает и спаны его транзакций, а не только сами транзакции, и безопасно повторяется после обрыва. Администратора инстанса нельзя удалить, пока на нём есть другие пользователи и роль не передана; гонка «удаляю себя, пока регистрируется другой» больше не может оставить инстанс без администратора.
• Эксплуатация (0.35.0). Контейнеры баз данных закреплены за digest образа, а не за подвижным тегом, — развёртывание не подхватит другой образ между двумя запусками. Остановка стека даёт обеим базам время закрыться штатно. Ошибки конфигурации при старте сообщаются все сразу, а не по одной на перезапуск; вычислитель SLO и уборщик выгрузок работают по бюджету тиков и сообщают о своей живости.

0.22.0–0.31.0 · 27 августа – 2 сентября 2026 — обзор проекта, ключи и безопасность

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

• Экран «Обзор» и новая навигация (0.29.0, 0.30.0). Проект открывается на «Обзоре»: строка состояния (аптайм, хосты за порогом, новые ошибки за сутки), открытые группы инцидентов и маркеры деплоев — вместо того, чтобы сразу бросать в список ошибок. У организации появился экран «Все проекты» в переключателе организации/проекта; вход без запомненного проекта ведёт туда. Меню разделено на три яруса (рабочие разделы, настройка, подвал), разделы названы по содержимому («Транзакции» стали «Производительностью», «Проблемы производительности» — «Узкими местами»), при этом адрес ни одной страницы не изменился. Массовые действия над ошибками переехали в панель над таблицей; поля форм и селекты выровнены по высоте в обеих темах.
• Выгрузки ошибок и событий (0.22.0–0.24.0). Фоновая выгрузка CSV/JSON/ NDJSON по группам ошибок или сырым событиям проекта с фильтром по периоду и окружению. PII маскируется по умолчанию — теперь включая stacktrace, breadcrumbs, user_id (стабильный псевдоним на выгрузку) и свободный текст; выгрузка «как есть» — только админам и владельцам организации. Состав групп фиксируется снимком до чтения, так что группа с новым событием посреди выгрузки больше не пропадает. Метаданные вынесены из тела файла (?meta=1, атрибуты на странице, строка в письме) — файлы снова читаются стандартными инструментами.
• Типы ключей и неймспейс /api/v1 (0.26.0, 0.27.0). У DSN-ключей появился тип — browser, server или agent — с правами ровно на то, что нужно источнику; новый проект получает три ключа сразу, хост регистрируется только ключом agent. Выпущенные ранее ключи работают без изменений. Логи, pprof-профили и маркеры деплоев принимаются по POST /api/v1/logs, /api/v1/profiles/pprof и /api/v1/{project}/deployments; старые пути работают, отвечают заголовком Deprecation и считаются метрикой gotcha_ingest_deprecated_path_total — удаление в 1.0 (в 0.37.0 срок перенесён на 2.0, см. секцию выше). OTLP и Sentry-совместимые эндпоинты не тронуты.
• Ротация ключа шифрования (0.25.0). GOTCHA_SECRET_KEY_PREV позволяет сменить GOTCHA_SECRET_KEY, не теряя client secret SSO, токены каналов и заголовки мониторов: старый ключ рядом с новым, перезапуск — и всё читаемое перешифровано. Значения несут версию формата и id ключа (enc:v2:<key-id>:...), ротацию можно проверить прямо в БД. Бэкфилл идёт при каждом старте и подбирает значения, оставшиеся открытым текстом со времён dev-ключа. Только вперёд: после записи первого enc:v2 откат на версию ниже 0.25.0 не поддерживается, а при rolling deploy ротацию ключа включать только после обновления всего парка.
• Hardening (0.23.0, 0.28.0). docker-compose.yml по умолчанию слушает 127.0.0.1 — голый HTTP и /metrics без аутентификации больше не смотрят наружу в обход HTTPS-прокси (GOTCHA_BIND=0.0.0.0 возвращает прежнее поведение). HSTS настраивается через GOTCHA_HSTS_*. Закрыты два пути неограниченного роста памяти рейт-лимитеров форм входа: ограничены длина ключа и тело запроса, у каждого лимитера жёсткий потолок ключей, проверка по IP идёт раньше проверки по аккаунту. Новая страница документации «Hardening»: прокси, служебные эндпоинты, TLS/HSTS, security.txt и самопроверка curl-ом.
• Надёжность оповещений (0.23.0). Uptime-мониторы участвуют в эскалации и подтверждаются, как остальные источники. Несостоявшаяся отправка «down» повторяется на следующей проверке (до пяти попыток), а при мёртвом канале инцидент несёт бейдж «уведомление не доставлено». Восстановление уходит только в каналы, получившие тревогу. Уведомления называют проект в теме, теле и webhook-payload. Heartbeat не засчитывается превью ссылок и префетчерам — переслать URL в чат больше не значит заглушить алерт. Квота логов редактируется в настройках организации.
• Self-метрики и канон конфигурации (0.23.0, 0.24.0). Новые метрики: отказы приёма по причине и сигналу, отказы по ключу, живость и длительность тика всех оценщиков, пропущенные ключи переводов, проигнорированные heartbeat-ы. Ломающее: метрики очередей приведены к схеме gotcha_<подсистема>_queue_*, а десять переменных окружения получили единицу измерения или верный префикс в имени (GOTCHA_RETENTION_DAYS → GOTCHA_EVENT_RETENTION_DAYS, GOTCHA_METRIC_EVAL_INTERVAL → ..._SECONDS и т. д.) — старые имена не читаются, старт с ними падает с указанием нового имени. Полная таблица — в CHANGELOG 0.24.0.
• Зум флеймграфа (0.31.0). Каждый кадр — ссылка: клик разворачивает его на всю ширину, предки остаются сверху как путь назад, строка «all» возвращает полный профиль. Зум живёт в адресе (focus=), им можно поделиться. Подписи привязаны к высоте строки и клипуются внутри кадра — на планшетах и телефонах они больше не вылезают за кадр.
• Также. Удаление проекта удаляет и его логи из ClickHouse; выгрузка и удаление персональных данных, а также инструкция по бэкапу теперь покрывают логи. Проход по вёрстке на 360px: заголовки, график частоты событий, карточки контекста, публичная страница статуса, пример на странице подключения SDK. Пул соединений PostgreSQL получил явные границы; очистка устаревших данных идёт и при старте; упавшая миграция ClickHouse больше не блокирует откат версии. Документация: страницы про лесенки эскалации и подавление зависимых алертов.

0.21.0 · 26 августа 2026 — группы инцидентов

• Каскад сворачивается в одну карточку. Когда падает узел, от которого зависят другие, сигналы раньше сыпались со всех сторон: молчат хосты за шлюзом, срабатывают метрические пороги, горит SLO монитора. Теперь корневой инцидент недоступности (тишина хоста или падение uptime-монитора) собирает вокруг себя состав — инциденты зависимых хостов, мониторов, метрических порогов с меткой host и uptime-SLO. Пока информирует корень, участники молчат и не эскалируют, а в уведомлении корня появляется строка «Зависимых узлов: N». После восстановления корня отпущенные участники оповещают заново, и лестница эскалации начинается с момента закрытия группы, а не с их собственного начала.
• Корень определяется по факту, а не по порядку событий. Отказ, который едет сверху вниз, тоже собирается правильно: если узел замолчал под уже упавшим родителем, более ранние инциденты его детей всё равно попадают в группу верхнего корня — даже когда этот корень сам является монитором.
• Лента инцидентов (раздел «Оповещения»). На одной странице: открытые группы с раскрываемым составом, инциденты вне групп по всем шести источникам и то, что закрылось за последние сутки. В составе группы видно, кто молчит потому, что информирует корень, а кто подавлен недоступным родителем — это два разных состояния, и они могут совпадать. Инцидент, переживший свою группу, сразу появляется среди внегрупповых со ссылкой на группу, из которой он пришёл.

0.18.0–0.20.0 · 20–21 августа 2026 — рецепты сервисов

• Рецепты мониторинга сервисов (0.19.0, 0.20.0). Готовые рецепты для PostgreSQL, nginx, Redis, Docker и MariaDB: конфиг OpenTelemetry-коллектора, автоопределение живых данных, преднастроенные графики и рекомендованные пороги в один клик — полезный мониторинг сервиса без ручного написания правил.
• Подавление зависимых алертов (0.18.0). У хостов и мониторов появились зависимости: при отказе родителя алерты его потомков глушатся автоматически — одно уведомление вместо шторма. Грейс-период на стабилизацию и восстановление без повторного шторма.

0.13.0–0.17.0 · 19–20 августа 2026 — умные алерты

Завершение августовского спринта: меньше ложных срабатываний, больше контроля над тем, кто и когда получает уведомления.

• Эскалация уведомлений (0.17.0). Лесенка ступеней на каждую критичность: каждая ступень расширяет круг получателей после настраиваемой задержки от открытия инцидента — одинаково для хостов, метрик, регрессий и SLO. Подтверждение инцидента оператором останавливает эскалацию; у каждого инцидента виден бейдж критичности. Раздел «Эскалации» настраивает лесенки с предпросмотром без отправки.
• Окна обслуживания для всего проекта (0.16.0). Окно глушит уведомления всех источников — аптайм, хосты, метрики, регрессии, профили, SLO и алерты об ошибках, — а не только проверок мониторов. Появился бессрочный тип окна для работ неизвестной длительности. Сбор данных и учёт инцидентов не затрагиваются.
• Сезонная база детектора регрессий (0.13.0). Детектор может сравнивать метрику с тем же окном того же дня недели за прошлые недели — сервисы с выраженным суточным профилем перестают «звенеть» на утреннем подъёме. При нехватке истории — автоматический откат на скользящую базу.
• Метки и пороги хостов (0.14.0, 0.15.0). Хосты помечаются окружением и ролью прямо из телеметрии — с фасетными фильтрами и группировкой. Каждый из четырёх встроенных порогов переопределяется на хост или группу по метке: каскад хост → роль → окружение → проект, на каждом уровне — наследовать, переопределить или выключить.

0.10.0–0.12.1 · 18–19 августа 2026 — SLO и контекст деплоев

• SLO и бюджеты ошибок (0.12.0). Цель уровня сервиса — availability, latency или uptime — на скользящем окне 1–90 дней. Двухоконный burn-rate алерт открывает инцидент, только когда и длинное, и короткое окно жгут бюджет выше порога. Экран SLO показывает достижение, остаток бюджета, график сжигания и историю инцидентов.
• Маркеры деплоев (0.11.0). CI сообщает о выкладке одним запросом; деплои видны вертикальными маркерами на графиках, а регрессия, начавшаяся в течение 7 дней после релиза, получает пометку «после деплоя vX» — виновника видно сразу.
• Карта зависимостей (0.10.0). Внешние зависимости сервиса — базы, кеши, внешние HTTP-вызовы — с частотой, задержкой (p50/p95) и долей ошибок. Строится из уже собираемых трейсов, настройки не требует.

0.7.0–0.9.0 · 18 августа 2026 — логи

Третий сигнал телеметрии: логи принимаются, хранятся, ищутся и склеиваются с остальными данными.

• Приём (0.7.0). OTLP/HTTP (POST /v1/logs) и построчный JSON (POST /logs), авторизация ключом проекта. Severity приводится к канону из шести уровней; у логов своя месячная квота и срок хранения, тело проходит тот же URL-скраб, что и сообщения ошибок.
• Экран логов (0.7.0). Фильтры по периоду, severity, сервису и окружению, полнотекстовый поиск, гистограмма объёма, фасеты со счётчиками, фильтры по атрибутам с автокомплитом, пагинация «показать старее».
• Склейка (0.9.0). «Логи вокруг события» со страницы ошибки, «логи этого трейса» с waterfall, «логи хоста» с карточки хоста.

0.5.0–0.6.2 · 14–17 августа 2026 — мониторинг хостов и нативный агент

• Раздел «Хосты» (0.5.0). Системные метрики серверов — CPU, память, диск, сеть, load average, процессы — отдельно от метрик приложения. Четыре встроенных порога (диск, память, нагрузка, «замолчал») открывают инциденты из коробки; онбординг выдаёт готовый конфиг коллектора с подставленным ключом.
• Нативный gotcha-agent (0.6.0). Один бинарь без зависимостей, ставится одной командой прямо с вашего инстанса — работает в закрытых сетях без выхода в интернет. Непривилегированный systemd-сервис, буферизует около часа недоставленных метрик. OpenTelemetry Collector остаётся полноценной альтернативой.
• Безопасность (0.5.1). Пересборка на Go 1.26.6 — закрыты семь уязвимостей стандартной библиотеки Go.
• Автономная сборка (0.6.2). Go-модули завендорены: сборка образа не ходит в интернет, make up-rebuild работает в закрытых сетях.

0.4.12 · 12 августа 2026 — операторская роль для команд

Сводный релиз (включает docs-обновление 0.4.11). Подробный разбор — в блоге.

• Операторская роль. Участники команды проекта ведут повседневный мониторинг без прав администратора организации: мониторы, пинг-токен heartbeat, окна обслуживания, контент статус-страниц, правила алертов и метрик-алерты. Каналы алертов остаются у owner/admin: получатель и секрет канала — учётные данные, а не операционная настройка; команде видны список каналов и журнал доставки с маскированными получателями.
• Безопасность. Заголовки мониторов (например, Authorization у HTTP-чека) шифруются при хранении — как секреты каналов. Публичный адрес статус-страницы — непрозрачный ключ /status/p_... вместо слага: имя нельзя ни подобрать, ни занять; старые ссылки работают через 301.
• Надёжность. Ingest: защита памяти при простое ClickHouse, честный учёт очередей и квот, атрибуция потерь по организациям. Повреждённый секрет канала больше не считается рабочим — алерты на этом пути не теряются. Фиксы консенсуса uptime-проверок, окон обслуживания и OAuth-приглашений.
• UX. Кнопка Copy на странице события — контекст ошибки в буфер одним кликом, в Markdown или как обычный текст.
• Доки. Раздел SDK покрывает расширения для CMS (WordPress, Joomla, 1С-Битрикс, Drupal, OpenCart, MODX, Tilda); инструкция по установке для AlmaLinux/RHEL.

0.4.10 · 5 августа 2026 — стабилизация линии 0.4.x

Итог двух полных аудитов продукта (эксплуатация, безопасность, доступность, i18n) и серии патчей 0.4.5–0.4.10:

• Эксплуатация. Compose-стек с лимитами памяти и healthcheck’ами; hardened-контейнер (read-only FS, no-new-privileges). Liveness и readiness разделены: /healthz и /readyz. --migrate-force восстанавливает прерванную миграцию; схема БД несёт маркер обратной совместимости — откат релиза больше не требует восстановления из бэкапа. Ретеншн настраивается отдельно для метрик, профилей и инцидентов.
• Сети с ограничениями. GOTCHA_TELEGRAM_API_BASE — свой Bot API-сервер для доставки в Telegram; GOTCHA_NET_MTU — MTU контейнерной сети для туннелей.
• Точность. Квота транзакций считается по сохранённому, а не по принятому; исправлены длительности перф-регрессий (µs читались как ms); алерты, ретраи и throttling считаются по часам БД.
• Безопасность. Удаление участника из организации отзывает и доступы его команд; регистрация по инвайту требует токен из ссылки; отсечка глубоко вложенного OTLP/JSON; усиленный redirect guard (по репорту CodeQL).
• Уведомления и UX. Единый язык уведомлений (GOTCHA_LOCALE); каналы «внутри периметра» с полными деталями; клавиатурная навигация, контраст и поддержка скринридеров по всему интерфейсу.

0.4.0 · 27 июля 2026 — окно времени и объяснимые перф-проблемы

• Единый контрол окна времени (1h / 24h / 7d / 30d / произвольный диапазон) на всех страницах с графиками.
• Страница перф-проблемы объясняет «что происходит и как чинить» для своего типа (N+1, медленный запрос, HTTP-флуд) — с полным SQL и локацией в коде.
• Полные детали запроса на странице ошибки: метод, URL, параметры, тело, заголовки (очищенные от PII).
• Подсказки к каждой метрике: p50–p99, failure rate, Apdex, Web Vitals.

0.3.x · 24–25 июля 2026 — надёжный uptime и малые серверы

• Ретраи на чек у uptime-мониторов — транзиентные сбои не рождают ложных инцидентов.
• График задержек с фазами DNS → TCP → TLS → TTFB; «частичный» статус доступности.
• Оверлей docker-compose.small.yml для минимальных серверов (2 vCPU / 2 ГБ).

0.1.0 · 22 июля 2026 — первый публичный релиз

Стартовый набор: ошибки (протокол Sentry SDK), распределённые трейсы и Web Vitals, метрики по OTLP, CPU-профили (flamegraph), uptime-мониторинг со статус-страницами, алерты в email/webhook/Telegram, организации и RBAC, SSO (OIDC, Yandex ID, VK ID), PII-скрабинг и SSRF-защита по умолчанию — один Go-бинарник с PostgreSQL и ClickHouse.