为什么你的 n8n 定时任务突然“罢工”了？
作为一个在自动化领域摸爬滚打多年的老司机，笔者见过太多次这种场景：早上满心欢喜地打开 n8n 面板，准备查看凌晨定时跑的数据，结果发现日志里空空如也，Cron 节点连个影子都没动。
这种“静默失败”最让人抓狂。你明明配置好了 0 0 * * *（每天午夜运行），系统却像个装睡的人，怎么叫都叫不醒。别急着骂街，这通常不是 n8n 的锅，而是你的配置或环境在“搞鬼”。
今天这篇来自 N8N大学 的硬核指南，不讲虚的，直接带你从表层现象挖到深层病灶，并附上高级定时策略，让你的自动化流程从此不再“失联”。
第一步：检查“发动机”是否启动（工作流状态）
这是最基础但也最容易被忽略的一步。n8n 的工作流有两种核心状态：激活（Active）和未激活（Draft）。
如果你的 Cron 节点配置得天衣无缝，但工作流右上角的开关处于“灰色”关闭状态，那么无论你设置什么时间，n8n 都不会执行它。这就像你车钥匙都没插进去，踩油门是没用的。
排查动作：
- 进入你的工作流界面，查看右上角的开关是否为 ON（绿色）。
- 如果是本地部署（Self-hosted），确保 n8n 服务正在运行。你可以通过
docker ps或查看 systemd 服务状态来确认。
第二步：揪出“时区”这个隐形杀手
这是 Cron 节点不执行的头号嫌疑人。很多新手在这里栽跟头，因为 n8n 的默认时区可能和你服务器的时区，或者你期望的时区不一致。
举个例子，你的服务器在纽约（UTC-5），而你希望在北京时间（UTC+8）早上 9 点运行。如果你只在 Cron 表达式里写 0 9 * * *，n8n 会认为这是纽约时间的 9 点，比你预期的时间晚了 13 个小时。
解决方案：
在 Cron 节点 的配置面板中，找到 Timezone（时区）字段。不要依赖默认值，手动输入你所在时区的 IANA 格式，例如 Asia/Shanghai 或 America/New_York。这是确保任务准时触发的铁律。
第三步：理解 n8n 的“懒惰”执行机制
如果你的 n8n 是通过 Docker 部署的，且没有使用外部触发器（如 Webhook），那么 n8n 的 Cron 节点是依赖于“轮询”的。这意味着：
n8n 不是一个独立的守护进程，它无法在后台“挂起”等待下一个 Cron 时间点。相反，它会在你设定的时间点附近，检查是否有任务需要处理。
关键点： 如果你的 n8n 容器在设定的时间点处于“休眠”状态（例如使用了 --restart unless-stopped 但流量极少导致容器被挂起），或者你手动重启了容器，Cron 任务就可能丢失。
硬核建议： 对于关键的定时任务，N8N大学 建议使用 Webhook 节点配合外部服务（如 Linux 的 Crontab 或云厂商的定时触发器）来调用。这样即使 n8n 重启，外部触发器也会在指定时间“敲门”，强制 n8n 唤醒执行。
第四步：日志里到底藏了什么秘密？
如果以上配置都正确，但任务还是没跑，你需要查看 n8n 的执行日志。n8n 的日志分为两种：Execution History（执行历史）和 System Logs（系统日志）。
Execution History： 在工作流界面点击 Execution History 按钮。如果你连一条记录都看不到，说明 Cron 根本没有触发。如果看到了记录但状态是红色的 Error，点击进去看具体的报错信息。
System Logs： 如果你是 Docker 部署，使用 docker logs <n8n_container_id> 查看容器输出。如果是 PM2 或 Systemd 启动，查看对应的日志文件。
常见的报错包括数据库连接失败、节点参数配置错误（例如引用了不存在的字段）。这些错误信息是修复问题的直接线索。
高级策略：如何构建坚不可摧的定时任务？
不想再为 Cron 的不执行而提心吊胆？试试 N8N大学 总结的这套高级策略，把“单点故障”变成“多重保险”。
1. 外部触发 + 内部队列
放弃单纯依赖 n8n 内部 Cron。改用 Linux Crontab 或 AWS EventBridge 等外部系统定时发送 HTTP 请求到 n8n 的 Webhook。
做法： 在 n8n 中使用 Webhook 节点接收请求，后接一个 Wait 节点或 Switch 节点进行分流。这样做的好处是，触发源在外部，更可控，且不易受 n8n 重启影响。
2. 错误重试与死信队列
任务执行了但失败了怎么办？在 n8n 工作流末尾增加判断逻辑。
做法： 在核心流程结束后，连接一个 If 节点，判断 {{ $json.error }} 是否存在。如果存在错误，将数据发送到一个专门的“重试工作流”或通过 Email / Slack 节点报警。不要让数据静默消失。
3. 健康检查心跳
你需要知道 n8n 本身是否还活着。
做法： 设置一个每小时运行一次的 Cron，专门用于发送“心跳”信号。如果连续两次没收到心跳（例如写入一个数据库表或发送一条 Slack 消息），立即触发报警。这能帮你第一时间发现服务宕机，而不是等到第二天早上才发现任务没跑。
常见问题 FAQ
Q1: 为什么我的 Cron 表达式写的是每分钟运行，但看起来每 5 分钟才运行一次？
A: 这通常是因为 n8n 的 Execution（执行）模式设置问题。如果工作流设置为 “在闲置时保存数据” 而不是 “每次发生变化时执行”，或者在 n8n 的全局设置中有限流配置，可能会导致触发频率被限制。检查工作流的触发器设置，确保没有开启不必要的“节流”选项。
Q2: 我重启了服务器，之前的 Cron 任务还会执行吗？
A: 取决于你如何重启。如果只是重启 n8n 服务，Cron 节点会重新加载时间表，通常不会丢失。但如果服务器关机了，n8n 无法“追赶”错过的执行时间。Cron 节点不会补偿执行（Backfill），错过的就错过了。这也是为什么建议使用外部触发器的原因之一。
Q3: 我可以在同一个工作流里放多个 Cron 节点吗？
A: 技术上可以，但不推荐。这样做会使工作流的逻辑变得混乱，且难以调试。N8N大学 建议将不同时间段的定时任务拆分为不同的独立工作流。这样，如果某个任务失败，不会影响其他任务，也便于在 n8n 的工作流列表中快速定位问题。
总结与资源
n8n 的 Cron 节点不执行，90% 的情况出在时区配置、服务状态和执行模式这三个环节。不要盲目修改表达式，先确认 n8n 的“心跳”是否正常。
对于关键业务，请务必采用“外部触发 + 内部队列”的双保险策略。自动化是为了省心，而不是为了增加焦虑。
如果你想深入学习 n8n 的高级架构设计，欢迎访问 N8N大学 (n8ndx.com)，这里有更多硬核的实战教程等你解锁。
