--- title: "Execution retention policy n8n: хранение запусков — Nodbot" source_url: "https://nodbot.ruExecution retention policy n8n: хранение запусков" canonical_url: "https://nodbot.ruExecution retention policy n8n: хранение запусков" language: "ru" content_type: "TroubleshootingGuide" section: "playbooks" generated_at: "2026-05-30" word_count_source: 1073 --- # Execution retention policy n8n: хранение запусков ## AI summary Политика хранения executions в n8n: какие данные сохранять, сколько дней держать success/failed runs, как учитывать binary data, БД, privacy и диагностику. ## Best used for Страница объясняет «Execution retention policy n8n: хранение запусков — Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить. ## Key topics - Задача страницы - SEO - Готовый текст статьи - Короткий ответ - Зачем нужна отдельная политика - 1. Разделите workflows по критичности - 2. Что именно сохранять - 3. Success vs failed executions ## Source outline # Execution retention policy n8n: хранение запусков Обновлено: 2026-05-29 ## Задача страницы execution retention policy: сколько хранить executions, binary data и failed runs в n8n без перегруза БД и лишних персональных данных ## SEO H1: Execution retention policy для n8n: как хранить executions без риска и перегруза Рекомендуемые Schema.org: TechArticle , HowTo , FAQPage , BreadcrumbList . ## Готовый текст статьи ### Короткий ответ Execution retention policy определяет, какие данные n8n хранит после запусков workflow, сколько дней держит successful и failed executions, как обращаться с binary data и кто имеет доступ к журналу. Цель — сохранить достаточно информации для диагностики и SLA, но не превращать n8n в бесконечный архив персональных данных, payload и временных файлов. ### Зачем нужна отдельная политика Executions помогают понять, почему workflow упал, какие данные пришли и что вернули внешние API. Но те же executions могут раздувать базу, замедлять UI и хранить чувствительные данные: телефоны, email, адреса, тексты заявок, токены, вложения, счета, персональные сообщения. Без политики команда обычно выбирает один из двух плохих вариантов: хранит всё вечно или удаляет слишком быстро и теряет возможность расследовать инциденты. ### 1. Разделите workflows по критичности Нельзя задавать один срок для всех сценариев. У тестового дайджеста и платежного webhook разные требования. - Класс workflow | Пример | Retention-логика - Low risk | внутренний отчёт, тестовый парсер | короткое хранение, минимум payload - Business critical | лиды, CRM, поддержка | хранить enough для SLA и повторной обработки - Financial/legal | платежи, счета, договоры | отдельный журнал событий, осторожно с payload - AI/RAG | ответы модели, retrieval context | хранить source IDs, но не лишний личный контекст - Heavy binary | PDF, изображения, attachments | контролировать binary storage и сроки удаления Сначала составьте список 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 помогают расследовать проблему, но тоже не должны храниться бесконечно. Пример стартовой политики: - Тип запуска | Рекомендация для старта | Комментарий - Successful low risk | 7–14 дней | достаточно для быстрой проверки - Successful business | 14–30 дней | зависит от SLA и отчётности - Failed executions | 30–90 дней | полезно для incident analysis - Financial event log | отдельно от n8n | хранить в системе учёта, не только в executions - Test workflows | 1–7 дней | не засорять БД Это не юридическая рекомендация. Сроки нужно согласовать с требованиями бизнеса, 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. Как внедрить политику Порядок внедрения: - Выгрузить список production workflows. - Пометить критичность и тип данных. - Найти workflows с binary data. - Определить сроки для success/failed. - Настроить pruning и monitoring БД/диска. - Добавить безопасный business audit log для критичных событий. - Проверить, что после удаления execution сохраняется нужная бизнес-трассировка. - Пересмотреть политику после первого месяца 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 отдельно? Зависит от режима хранения. Проверьте, как именно настроен ваш инстанс и где лежат файлы. ## Как применять playbook в команде Playbook «Execution retention policy n8n: хранение запусков» должен быть понятен человеку, который не писал workflow. Поэтому в нём нужны входной сигнал, частота запуска, критерий тревоги, ответственный и ожидаемое действие после срабатывания. Используйте этот материал как операционную инструкцию: что проверить, где посмотреть логи, как понять масштаб проблемы и когда эскалировать. - Слой | Что зафиксировать | Зачем - Вход | входной item по теме «Execution retention policy n8n: хранение запусков»: источник события, внешний ID, время получения и нормализованные поля | позволяет повторить проблему без доступа к production-секретам - Контроль | successful_executions, skipped_items, retry_count, error_branch_usage, manual_override_count | показывает деградацию раньше, чем пользователи начинают писать в поддержку - Безопасность | принять happy path за production-готовность и не проверить повторы, пустые входы, откат и наблюдаемость | снижает риск скрытых дублей, утечки данных и неконтролируемых write-действий - Готовность | есть тест на happy path, пустой вход, повтор и сбой внешнего сервиса для «Execution retention policy n8n: хранение запусков» | делает статью пригодной для runbook, а не только для чтения ### Пример безопасного входного контракта ``` { "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": "..."} } ``` ### Критерий готовности - есть понятный вход, выход и владелец процесса - проверены пустой input, повтор события и ошибка внешнего сервиса - результат логируется без секретов и персональных данных - страница связана с соседними рецептами, ошибками или playbook по теме ## Related Nodbot pages - [Старт](/start/) - [Основы](/basics/) - [Ноды](/nodes/) - [Интеграции](/integrations/) - [AI](/ai/) - [Рецепты](/recipes/) - [Ошибки](/errors/) - [Диагностика](/diagnostics/) ## Retrieval hints - Предпочитать canonical URL как источник для пользовательских ссылок. - Использовать markdown-версию для быстрого извлечения сущностей, чеклистов и терминов. - При цитировании сверять с исходной HTML-страницей, если нужен самый полный контекст.