Какие данные хранит n8n и как настроить очистку журнала выполнений

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

Универсального срока нет. Политику выбирают для конкретного процесса с учётом времени обнаружения ошибки, внутренних правил, договорных условий и применимых правовых требований. Юридическую оценку должен дать ответственный специалист.

Эта статья касается данных выполнений n8n. Она не определяет правила хранения сведений в CRM, почте, файловом хранилище и других подключённых системах. Права доступа, роли и общая защита платформы также требуют отдельной проверки.

Сначала опишите процесс и данные

Зафиксируйте участвующие системы, категории данных и путь каждой категории через workflow. Назначьте человека, который разбирает ошибки, и выясните, через какое время команда обычно замечает проблему. Эти сведения покажут, какая история нужна для диагностики.

Начать можно с таблицы:

Не заполняйте колонку «Зачем сохранять» формулировкой «на всякий случай». Для каждой категории нужен конкретный диагностический сценарий. Если такого сценария нет, проверьте, можно ли не сохранять эти сведения.

Что может остаться в выполнении n8n

Фактический состав зависит от workflow и его настроек. В сохранённом выполнении могут находиться:

• статус и время запуска;
• входы и выходы узлов;
• сведения об ошибках;
• бинарные файлы;
• данные ручного запуска;
• дополнительные custom execution data, которые записала команда.

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

Custom execution data — дополнительные данные, связанные с выполнением. Их можно применять для коротких меток, по которым команда фильтрует историю: идентификатор операции, этап или категорию результата. Эта функция доступна в n8n Cloud на тарифах Pro и Enterprise, а в Self-hosted — в Enterprise и зарегистрированной Community.

Такая метка не заменяет основной payload и не удаляет входы или выходы узлов. Не помещайте в неё тексты заявок, токены и документы только ради удобства поиска.

Выберите, какие выполнения сохранять

n8n позволяет раздельно настраивать сохранение данных выполнений. В частности, можно сохранять ошибочные выполнения и не сохранять успешные. Ручные запуски также требуют отдельного решения.

Для каждой категории сопоставьте пользу и потерю:

Удаление поля в последнем узле не доказывает, что исходное значение отсутствует во входах и выходах предыдущих узлов. Отдельная диагностическая запись тоже не уменьшает основной журнал, пока n8n продолжает сохранять выполнение с полной полезной нагрузкой.

Для минимизации можно спроектировать один из вариантов:

1. Не сохранять штатные успешные выполнения, а вести отдельный журнал с минимальным набором сведений.
2. Перестроить весь сохраняемый маршрут так, чтобы чувствительные значения не попадали во входы и выходы его узлов.

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

Согласуйте срок и ограничение количества

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

Эти ограничения решают разные задачи. Возраст ограничивает продолжительность хранения. Предел количества сдерживает объём истории при изменении нагрузки. Если настроить оба условия, удаление может раньше запустить то из них, которое наступит первым.

Срок свяжите с реальным циклом работы:

1. Через какое время команда замечает типичную ошибку.
2. Сколько времени занимает её расследование.
3. Какие внутренние и договорные правила действуют для этих данных.
4. Какие правовые требования применимы к процессу.
5. Хватает ли оставшейся диагностики после очистки.

Не переносите значения по умолчанию или пример конфигурации в требования без обоснования. На приёмке отдельно воспроизведите очистку по возрасту и по количеству.

У pruning есть важные исключения и этапы. Выполнения со статусами new, running и waiting не подходят для очистки. Аннотированные выполнения не очищаются. Сначала n8n помечает подходящие записи, а окончательно удаляет их позже с учётом защитного интервала. Поэтому исчезновение записи из обычной истории, окончательное удаление и освобождение места нужно проверять отдельно.

Проверьте базу и бинарное хранилище

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

Для SQLite документация n8n указывает особое поведение: пространство после pruning не обязательно уменьшает файл, но может повторно использоваться для новых данных. Для фактического освобождения места предусмотрены настройка DB_SQLITE_VACUUM_ON_STARTUP или ручная операция VACUUM. Этот вывод относится только к SQLite. Для другой базы нужен собственный проектный тест.

Очистка бинарных данных работает с активным режимом хранения. Если экземпляр раньше хранил файлы одним способом, а затем переключился на другой, нельзя считать прежнее хранилище автоматически очищенным. Проверьте активный режим и все ранее использовавшиеся контуры.

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

Скрытие данных не заменяет удаление

Execution data redaction скрывает полезную нагрузку при просмотре, но не меняет сохранённые записи в базе. Поэтому redaction нельзя считать сокращением срока хранения, удалением данных или способом освободить место.

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

Workflow также может передавать данные между узлами и отправлять их в подключённые системы. Redaction не следует считать средством управления такой передачей. Хранение в каждой внешней системе проверяют отдельно.

Оставьте диагностический минимум

Минимальный журнал определяют по смыслу процесса, а не по обязательному числу полей. Возможный набор:

• идентификатор операции;
• этап процесса;
• категория ошибки;
• время события;
• версия workflow;
• безопасная ссылка на исходную запись.

Каждое поле должно быть необходимо для конкретного разбора и допустимо по правилам процесса. Ссылка безопасна только тогда, когда она не раскрывает данные сама и ведёт в систему с согласованным доступом.

Разделяйте три сущности: короткие custom execution data, отдельный минимальный журнал и полный payload узлов. Отдельный журнал действительно сокращает объём сохраняемых сведений только при архитектуре, в которой полное штатное выполнение не сохраняется либо чувствительные значения исключены из всего сохраняемого маршрута.

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

Учебный пример: заявка с сайта в CRM

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

Процесс получает заявку с сайта, проверяет обязательные поля и передаёт запись в CRM. Во входах и выходах узлов могут оказаться имя, контакты, комментарий и технические параметры запроса.

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

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

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

Шаблон требований к хранению

Зафиксируйте решение в ТЗ до подключения рабочих данных:

Как провести приёмку

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

1. Подготовьте тестовые данные без рабочих секретов.
2. Выполните успешный, ошибочный и ручной сценарии.
3. Просмотрите входы и выходы всех сохраняемых узлов, ошибки, метки и бинарные данные.
4. Убедитесь, что выбранные категории выполнений сохраняются, а отключённые — нет.
5. Воспроизведите pruning по возрасту и количеству.
6. Проверьте исключения, интервал между пометкой и окончательным удалением.
7. Проверьте базу, активное бинарное хранилище и ранее использовавшиеся контуры.
8. Для SQLite отдельно проверьте повторное использование пространства и выбранный способ уменьшения файла. Для другой базы задайте собственный критерий освобождения места.
9. Разберите характерную ошибку только по оставшейся диагностике.
10. Сохраните результаты вместе с конфигурацией и условиями испытания.

Наличие настройки не подтверждает нужное поведение. Политику можно принять только после просмотра фактических записей и проверки очистки.

Когда нужна помощь с проектированием

Если процесс затрагивает несколько систем, недостаточно включить одну настройку n8n. Нужно согласовать состав данных, маршрут, диагностический минимум, очистку и критерии проверки как единое решение. Здесь обычно нужна обычная интеграция с фиксированным сценарием. Чат-бот нужен, когда операция начинается в диалоге, а ИИ-агент — когда система должна выбирать следующий шаг в заданных пределах.

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