# Мониторинг по сценарию

Тест на Playwright по расписанию: вход, корзина, оплата и запросы к API

> Индекс всей документации в markdown: https://statuser.cloud/llms.txt — там перечислены остальные статьи. Всё одним файлом: https://statuser.cloud/llms-full.txt. Документация API: https://statuser.cloud/api-reference.md

## Доступность по тарифам

Доступно в тарифах Pro и Team

| Функция | Free | Pro | Team |
| --- | --- | --- | --- |
| Сценарные проверки | нет | до 10 сценариев | до 100 сценариев |
| Частота сценарных проверок | нет | от 15 минут | от 10 минут |
| Таймаут сценария | нет | до 60 секунд | до 2 минут |

Сценарии занимают места серверов тарифа: их можно завести до 20% от лимита серверов.

Сравнение тарифов: https://statuser.cloud/pricing

## Через API и MCP

Описанное в статье можно сделать программно — запросом к публичному API или через MCP-сервер Statuser, который работает поверх того же API. Понадобится API-ключ, создать его можно на любом тарифе; ограничения тарифа в API те же, что в интерфейсе.

- Документация API: https://statuser.cloud/api-reference (машиночитаемо: https://statuser.cloud/api-reference.md)
- MCP-сервер: https://github.com/statuser-cloud/mcp

---

Сценарий проверяет сайт так, как им пользуется человек: открывает страницы в настоящем браузере, входит в личный кабинет, кладёт товар в корзину и смотрит, что на экране то, что должно быть. Обычная HTTP-проверка увидит, что сайт ответил `200`, но не заметит, что кнопка входа перестала работать, а каталог открывается пустым.

Сценарий — это тест на [Playwright](https://playwright.dev/docs/intro). Statuser запускает его по расписанию в браузере на своей стороне и открывает инцидент, если тест упал.

## Как включить

При добавлении сервера выберите тип мониторинга **Сценарий** и заполните:

- **Название** — оно показывается в списке серверов, на страницах статуса и в уведомлениях. Например, «Вход в личный кабинет».
- **Сценарий** — код теста. В новом сервере уже лежит пример, с которого удобно начать.
- **Переменные окружения** — логины, пароли и токены, которые нужны тесту. Подробнее — в разделе [Пароли и токены](#пароли-и-токены).
- **Откуда проверять** — город, из которого откроется сайт.
- **Таймаут сценария** — сколько может длиться весь прогон.
- **Интервал проверки** — как часто запускать сценарий.

![Форма нового сервера с типом «Сценарий»: редактор кода с примером теста, кнопка добавления переменной окружения, блок «Проверить сценарий» с кнопкой «Запустить», город, таймаут и интервал проверки](https://statuser.cloud/docs/screens/scenario-monitoring-form-light.png)

Перед сохранением нажмите **Запустить** в блоке **Проверить сценарий**: Statuser прогонит тест так же, как по расписанию, и покажет результат со скриншотом, видео и трейсом.

## Как написать сценарий

Сценарий можно записать в Codegen, поручить ИИ или написать по примерам ниже.

### Записать в Codegen

Проще всего не писать тест руками, а записать. Установите [Node.js](https://nodejs.org/) и запустите запись:

```bash
npx playwright codegen https://example.com
```

Откроется браузер. Пройдите путь, который хотите проверять, — Codegen превратит каждое действие в строку кода. Скопируйте код в поле **Сценарий** и добавьте проверки: что после входа видно имя пользователя, что в корзине появился товар.

### Попросить ИИ

Тест можно поручить ИИ-ассистенту — [Statuser AI](/docs/ai-assistant) в панели или любому другому. Опишите путь по шагам и что считать успехом и попросите тест на `@playwright/test` одним файлом. Чтобы черновик заработал с первого раза, добавьте в запрос несколько условий:

- искать элементы по роли и подписи (`getByRole`, `getByLabel`), а не по CSS-классам — такие тесты переживают редизайн;
- после каждого важного шага ставить проверку `expect`;
- логин и пароль брать из `process.env`, а не вписывать в код;
- обойтись без `playwright.config` и своих таймаутов — их задаёт Statuser.

Например:

```plaintext
Напиши тест на @playwright/test одним файлом: открыть https://example.com/login,
войти с логином из process.env.LOGIN и паролем из process.env.PASSWORD
и проверить, что появилась надпись «Мой профиль».
Элементы ищи через getByRole и getByLabel, конфиг не нужен.
```

ИИ не видит ваш сайт и может ошибиться в подписях кнопок и полей — сверьте их со страницей или запишите проблемный шаг в Codegen. Настоящие пароли в чат ассистента не вставляйте: в тест они придут из переменных окружения. Готовый черновик проверьте кнопкой **Запустить**.

### Вход в личный кабинет

```ts
import { test, expect } from '@playwright/test';

test('вход в личный кабинет', async ({ page }) => {
  await page.goto('https://example.com/login');
  await page.getByLabel('Email').fill(process.env.LOGIN!);
  await page.getByLabel('Пароль').fill(process.env.PASSWORD!);
  await page.getByRole('button', { name: 'Войти' }).click();
  await expect(page.getByText('Мой профиль')).toBeVisible();
});
```

Проверки (`expect`) — главное в сценарии. Без них тест пройдёт, даже если после входа открылась страница с ошибкой: сам по себе Playwright следит только за тем, что элементы, с которыми вы работаете, нашлись на странице.

### Цепочка запросов к API

Сценарий не обязан открывать браузер. Через `request` можно проверить API, в котором один запрос зависит от другого, — например, получить токен и сходить с ним в защищённый метод:

```ts
import { test, expect } from '@playwright/test';

test('API: вход и профиль', async ({ request }) => {
  const login = await request.post('https://api.example.com/auth', {
    data: { login: process.env.LOGIN, password: process.env.PASSWORD },
  });
  expect(login.ok()).toBeTruthy();
  const { token } = await login.json();

  const profile = await request.get('https://api.example.com/me', {
    headers: { Authorization: `Bearer ${token}` },
  });
  expect(profile.status()).toBe(200);
});
```

Куки, которые вернул один запрос, `request` подставляет в следующие сам — сессионную куку передавать руками не нужно.

### Несколько проверок в одном сценарии

В сценарии может быть несколько тестов (`test(...)`). Они выполняются по очереди, и сценарий считается упавшим, если упал хотя бы один. Если шаги не связаны друг с другом — например, вход и поиск по каталогу, — удобнее завести два сервера: по инциденту сразу будет понятно, что именно сломалось.

## Пароли и токены

Не вписывайте секреты в код. Добавьте их кнопкой **Добавить переменную окружения** и читайте в тесте через `process.env`, как в примерах выше.

- Имя — латинские буквы в верхнем регистре, цифры и `_`, например `PASSWORD`.
- До **20** переменных. Значение одной — до **4 КБ**, это около 4000 символов латиницей: хватит на пароль, токен или ключ.
- Некоторые имена задать нельзя — они нужны Statuser, чтобы запустить тест. Это имена с префиксами `PLAYWRIGHT_`, `PW_`, `PWTEST_`, `PWDEBUG`, `DEBUG`, `NODE_`, `LD_` и `STATUSER_`, а также `PATH`, `HOME`, `TMPDIR`, `CI`, `FORCE_COLOR`, `HTTP_PROXY`, `HTTPS_PROXY`, `NO_PROXY` и `ALL_PROXY`.

Значения хранятся в зашифрованном виде и после сохранения не показываются: поле остаётся пустым с подсказкой **Сохранено — оставьте пустым**. Чтобы сменить значение, введите новое.

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

## Откуда идёт проверка

Сценарий открывает сайт из выбранного города: Москвы, Санкт-Петербурга, Амстердама, Алматы или Нью-Йорка. Город один, и запасного нет: от адреса зависит то, что сценарий часто и проверяет, — геоблоки, белые списки, язык и цены. Выберите город, из которого сайтом пользуются ваши клиенты.

Запросы идут с тех же IP-адресов, что остальные проверки Statuser, а User-Agent у сценария — как у настольного Chrome, с меткой `Statuser Bot`. Если Statuser уже пропущен в файрволе, добавлять ничего не нужно, а как настроить правило — в статье [User-Agent и IP-адреса Statuser](/docs/statuser-user-agent-and-ips#user-agent-сценариев).

## Как проходит прогон

- **Таймаут — на весь сценарий**, а не на один шаг, как в Playwright по умолчанию. Не уложился — прогон считается упавшим. Варианты: **15**, **30**, **45** секунд, **1** и **2** минуты.
- **Интервал** — от **10** минут до **суток**.
- **Повторов нет**: каждый прогон — одна попытка. Если сайт иногда отвечает медленно и тест из-за этого падает, добавьте повтор в сам сценарий строкой `test.describe.configure({ retries: 1 });` — он уложится в тот же таймаут.
- **Каждый прогон начинается с чистого листа**: новый браузер без кук и кеша. Между прогонами ничего не сохраняется — если тесту нужна авторизация, он входит сам.

## Когда открывается инцидент

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

В карточке инцидента — шаг, на котором упал тест, текст ошибки, консоль браузера, скриншот, видео прогона и трейс. Трейс открывается во встроенном просмотрщике Playwright: в нём можно пройти сценарий по шагам, посмотреть страницу до и после каждого действия, сетевые запросы и консоль.

![Инцидент сценария «Оформление заказа»: превью скриншота страницы, упавший тест «оформление заказа», время прогона и город, текст ошибки Playwright с журналом вызовов и кнопки «Открыть видео», «Открыть трейс» и «Скачать трейс»](https://statuser.cloud/docs/screens/scenario-monitoring-incident-light.png)

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

Сами файлы хранятся, пока существует инцидент, а файлы пробных прогонов — сутки.

## Как запустить вручную

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

Ручных запусков — не больше **30** за **10** минут и по одному одновременно на аккаунт.

## Что важно учитывать

- **Только публичные адреса.** Сценарий открывает сайты и API, доступные из интернета.
- **Порты** — `80`, `443` и от `1024`: этого хватает сайтам и API, в том числе на нестандартных портах вроде `8443` или `3000`.
- **Скачивание файлов** в браузере выключено.
- **Память** — около **1,2 ГБ** на прогон. Сценарий, которому нужно больше, останавливается с ошибкой о превышении памяти.
- **Код** — до **64 КБ**, это больше **тысячи** строк. Тест входа из примера выше занимает меньше половины килобайта.
- **Сценарий входит в лимит серверов тарифа.** Сколько сценариев можно завести, как часто их проверять и какой таймаут поставить на каждом тарифе — на странице [Тарифы](/pricing).

---

Источник: https://statuser.cloud/docs/scenario-monitoring