Execution retention policy n8n: хранение запусков ¶

Обновлено: 2026-05-29

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

Execution retention policy определяет, какие данные n8n хранит после запусков workflow, сколько дней держит successful и failed executions, как обращаться с binary data и кто имеет доступ к журналу. Цель — сохранить достаточно информации для диагностики и SLA, но не превращать n8n в бесконечный архив персональных данных, payload и временных файлов.

Зачем нужна отдельная политика ¶

Executions помогают понять, почему workflow упал, какие данные пришли и что вернули внешние API. Но те же executions могут раздувать базу, замедлять UI и хранить чувствительные данные: телефоны, email, адреса, тексты заявок, токены, вложения, счета, персональные сообщения.

Без политики команда обычно выбирает один из двух плохих вариантов: хранит всё вечно или удаляет слишком быстро и теряет возможность расследовать инциденты.

1. Разделите workflows по критичности ¶

Нельзя задавать один срок для всех сценариев. У тестового дайджеста и платежного webhook разные требования.

Сначала составьте список production workflows и назначьте каждому класс хранения.

2. Что именно сохранять ¶

Не все execution data одинаково полезны. Для диагностики часто нужен не весь payload, а ключевые ID, статусы и ошибки.

Сохраняйте:

• execution ID;
• workflow name/version;
• external event ID;
• order/payment/ticket/lead ID;
• итоговый статус;
• код ошибки и короткий текст;
• время начала и завершения;
• ссылку на внешний объект.

Ограничивайте:

• полный raw payload;
• вложения и binary data;
• персональные сообщения клиентов;
• содержимое документов;
• API responses с tokens;
• prompts с приватным контекстом.

Хорошая практика — делать отдельный audit log с безопасными полями, а не полагаться только на executions.

3. Success vs failed executions ¶

Successful executions обычно нужны меньше, чем failed. Failed runs помогают расследовать проблему, но тоже не должны храниться бесконечно.

Пример стартовой политики:

Это не юридическая рекомендация. Сроки нужно согласовать с требованиями бизнеса, privacy и регуляторики.

4. Binary data и тяжёлые payload ¶

Если workflow работает с PDF, изображениями, CSV, аудио, вложениями писем или выгрузками, именно binary data могут быстро съесть диск. Такие workflow нужно отдельно пометить в политике.

Проверьте:

• где хранится binary data: memory, filesystem, external storage;
• удаляется ли binary data вместе с execution data;
• есть ли workflow, который временно хранит большие файлы;
• нужен ли файл после обработки;
• можно ли сохранять только ссылку на файл в внешнем хранилище;
• есть ли алерт на disk usage.

Если файл нужен бизнесу, лучше хранить его в предназначенной системе: CRM, S3-like storage, document management, а в n8n оставлять ссылку и checksum.

5. Доступ к executions ¶

Retention — это не только сроки, но и доступ. Даже коротко хранимые данные опасны, если их видит вся команда.

Минимальные правила:

• доступ к executions имеют только нужные роли;
• production и staging разделены;
• чувствительные workflow отмечены владельцем;
• screenshots executions не уходят в публичные чаты;
• export workflow не содержит секретов и реальных payload;
• при инциденте фиксируется, кто смотрел данные.

Особенно аккуратно с AI-workflows: prompt, context и model response могут содержать больше персональных данных, чем кажется.

6. Как внедрить политику ¶

Порядок внедрения:

1. Выгрузить список production workflows.
2. Пометить критичность и тип данных.
3. Найти workflows с binary data.
4. Определить сроки для success/failed.
5. Настроить pruning и monitoring БД/диска.
6. Добавить безопасный business audit log для критичных событий.
7. Проверить, что после удаления execution сохраняется нужная бизнес-трассировка.
8. Пересмотреть политику после первого месяца production.

Не включайте агрессивное удаление, пока не проверили, что команда всё ещё может расследовать инциденты.

7. Smoke test политики ¶

Проведите тест:

• создать тестовое событие с уникальным ID;
• убедиться, что execution виден сразу после запуска;
• проверить, какие поля сохранены;
• проверить, что sensitive fields не сохраняются лишний раз;
• дождаться или смоделировать pruning;
• убедиться, что business audit log всё ещё содержит нужный ID и статус.

Политика работает, если после pruning можно ответить: событие было, обработано/не обработано, результат такой, внешний объект такой.

FAQ ¶

Можно ли хранить executions вечно?
Технически иногда можно, но это ухудшает производительность и повышает privacy-риск. Лучше определить осмысленные сроки.

Что хранить для платежей?
В n8n — минимум для диагностики: event ID, payment ID, статус, время, execution ID. Финальный источник правды должен быть в платёжной системе и учётной системе.

Что делать с failed executions?
Хранить дольше, чем successful, но с понятным сроком. Если ошибка критична, создавайте incident note или ticket, а не держите всё только в n8n.

Нужно ли удалять binary data отдельно?
Зависит от режима хранения. Проверьте, как именно настроен ваш инстанс и где лежат файлы.

{
  "source": "manual|webhook|schedule|api",
  "external_id": "stable-id-from-source",
  "received_at": "2026-05-29T10:00:00Z",
  "payload_version": "v1",
  "dry_run": true,
  "audit": {"workflow_id": "...", "execution_id": "..."}
}