Мониторинг сайта на Tilda: что можно собрать без доступа к серверу

2026-08-08 · Автор OtezVikentiy

Все предыдущие статьи этой серии — WordPress, Joomla, 1С-Битрикс, Drupal, OpenCart, MODX — начинались одинаково: ставим расширение, которое подключает Sentry SDK на стороне PHP. С Tilda так не выйдет: это SaaS, чужой сервер, никакого PHP. Значит, и разговор другой — не «как подключить всё», а «что из этого вообще достижимо».

Короткий ответ: примерно половина, и это по-прежнему полезная половина.

Что можно и чего нельзя

Сигнал	На CMS со своим сервером	На Tilda
Ошибки JavaScript у посетителей	да	да
Web Vitals (LCP, INP, CLS, FCP, TTFB)	да	да
Аптайм и срок SSL-сертификата	да	да
Алерты в Telegram/webhook/email	да	да
Ошибки PHP на сервере	да	нет: чужой сервер
Время ответа по эндпойнтам	да	нет: нет доступа к бэкенду
Трейсы и профилирование	да	нет
Бизнес-метрики из базы	да	нет прямого доступа к БД

Строчки «нет» — не про недостаток Gotcha, а про природу конструктора: код на сервере Tilda исполняется не ваш, и повлиять на него нельзя ни одним мониторингом. Зато всё, что происходит в браузере посетителя и снаружи сайта, доступно полностью.

Причём именно эти две группы обычно и отвечают за «сайт вроде работает, а заявок нет»: сломанная форма, не загрузившийся скрипт, просроченный сертификат.

Где взять DSN

После создания проекта Gotcha перекидывает на страницу «Подключение» (/projects/<id>/setup). DSN выглядит так:

https://<public_key>@gotcha.example.com/<project_id>

public_key в нём публичен по замыслу — именно поэтому DSN можно спокойно вставлять в HTML-код страницы, которую видят все.

Куда вставлять код

У Tilda есть штатное место для произвольного кода в <head>:

Настройки сайта → Ещё → HTML-код для вставки внутрь HEAD

Вставленное туда попадёт на все страницы сайта — именно это и нужно мониторингу. Есть и вариант «на одну страницу» (Настройки страницы → Дополнительно → HTML-код в HEAD), но для мониторинга он бессмысленен: ошибки интересны везде.

Вставлять в <body> или блоком T123 (HTML-код на странице) не стоит: SDK должен стартовать раньше остальных скриптов, иначе ошибки, случившиеся до него, потеряются. Ради этого он и живёт в <head>.

Сам код

<script src="https://ваш-хостинг.example.com/sentry.min.js"></script>
<script>
  Sentry.init({
    dsn: "https://<public_key>@gotcha.example.com/<project_id>",
    environment: "production",
    integrations: [Sentry.browserTracingIntegration()],
    tracesSampleRate: 0.2
  });
</script>

browserTracingIntegration сам снимает Web Vitals (LCP, CLS, INP, FCP, TTFB) и создаёт транзакцию загрузки страницы; Sentry.init без дополнительных настроек уже ловит необработанные ошибки JavaScript и отклонённые промисы.

Откуда брать сам бандл

Современный @sentry/browser не публикует в npm готовую браузерную сборку — её собирают сами. Один раз собрать и положить рядом со своим инстансом Gotcha (или на любой свой статический хостинг) — предпочтительный вариант:

npm i @sentry/browser esbuild
npx esbuild <(echo "export * from '@sentry/browser'") \
  --bundle --minify --format=iife --global-name=Sentry \
  --outfile=sentry.min.js

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

Если своего места под файл нет, есть официальный CDN Sentry. Тогда обязательно указывайте integrity с точной версией: без него вы доверяете чужому серверу выполнение произвольного кода на своём сайте.

<script src="https://browser.sentry-cdn.com/10.69.0/bundle.tracing.min.js"
        integrity="sha384-Xl/pZ2YgviohWlNZ2ipnBKfonCQ2EKaXzusUClBh8mrgAiDZa3outR+4H52ZSOz9"
        crossorigin="anonymous"></script>

Хеш посчитан для версии 10.69.0 (openssl dgst -sha384 -binary bundle.tracing.min.js | openssl base64 -A). При смене версии его нужно пересчитать — в этом и смысл: подменённый файл просто не выполнится.

Кардинальность: единственная настройка, о которой стоит подумать

Браузерный SDK называет транзакцию загрузки по пути URL. Для лендинга на пять страниц это идеально: /, /about, /price — ровно то, что хочется видеть в отчёте.

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

Лечится это на стороне SDK — нормализацией имени перед отправкой:

Sentry.init({
  dsn: "https://<public_key>@gotcha.example.com/<project_id>",
  integrations: [Sentry.browserTracingIntegration()],
  tracesSampleRate: 0.2,

  beforeSendTransaction: function (event) {
    // /blog/kak-my-pochinili-nginx  ->  /blog/:slug
    event.transaction = event.transaction
      .replace(/^\/blog\/[^/]+$/, '/blog/:slug')
      .replace(/^\/catalog\/[^/]+$/, '/catalog/:slug');

    return event;
  }
});

Правила пишутся под структуру конкретного сайта: разделов на Tilda обычно немного, и одного-двух replace хватает. Если страниц действительно мало — ничего настраивать не нужно.

Аптайм и SSL: то, ради чего это всё стоит включить

На Tilda мониторинг доступности даже важнее, чем на своём сервере: вы не видите логов, не видите нагрузки и узнаете о проблеме только от клиента. Аптайм не требует вообще никакого кода — Gotcha ходит на публичный URL снаружи:

Аптайм → Новый монитор → HTTP, адрес сайта, интервал и пороги отказа/восстановления. Инциденты, предупреждение об истекающем SSL-сертификате и публичная status-страница — из коробки (Аптайм).

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

Алерты

В разделе «Оповещения» правила (новый issue, регрессия, всплеск) уже включены; остаётся добавить канал доставки — Telegram, webhook или email. Каналы привязываются и к аптайм-мониторам, так что падение сайта и новая ошибка JS приходят в одно и то же место (Алерты).

Что смотреть на сайте под Tilda в первую очередь

Метрика	Зачем
Ошибки JS по браузерам	форма или квиз не отправляются у части посетителей
Ошибки со сторонних скриптов	виджеты чатов и аналитики ломаются чаще самого сайта
Web Vitals (LCP, INP, CLS)	реальная скорость у людей, а не в Lighthouse
Аптайм	сайт недоступен — узнать раньше клиента
Срок SSL	сертификат истекает через три дня

Про сторонние скрипты стоит сказать отдельно: на типичном сайте под Tilda их больше, чем собственного кода — метрика, чаты, пиксели, калькуляторы. Именно они чаще всего и падают, и без мониторинга это невидимо: страница выглядит целой, просто кнопка не работает.

Итог

Tilda — SaaS, и серверную половину мониторинга получить нельзя: ни ошибок PHP, ни времени ответа, ни трейсов. Это ограничение конструктора, а не инструмента.
Браузерная половина доступна полностью: ошибки JavaScript и Web Vitals подключаются одним блоком в Настройки сайта → Ещё → HTML-код внутрь HEAD.
Бандл лучше держать у себя, а не тянуть с чужого CDN: мониторинг должен работать тогда, когда всё остальное сломалось.
Если страниц много — нормализуйте имена транзакций через beforeSendTransaction, иначе отчёт утонет в адресах.
Аптайм и SSL не требуют кода вовсе и на конструкторе полезны даже больше, чем на своём сервере: логов вы всё равно не увидите.

Дальше — документация, установка Gotcha и раздел подключения SDK.