Make Your Money Triggers Fire After a Restart: A Solo Operator's n8n 2.45 Audit

A restart is the real test

When your server restarts, the invoice reminder either fires late or it does not. That is the only question that matters for a money trigger. For a solo business, that reminder, the billing check, and the customer follow-up are not automatic until you have watched them survive a restart. n8n released version 2.45.0 on October 20, 2026. From that release, the durable scheduler is the default. It writes each scheduled run to the database before the run is due, so a restart does not drop the run. If downtime passes a due run, it can still run late as long as the grace period has not closed; once it has, the trigger's misfire rule takes over.

A restart is the moment when a workflow stops being a diagram and becomes a real event. A morning invoice reminder can arrive late instead of disappearing. A billing check may run after its due time, and a late run can duplicate work. The scheduler makes the late run possible; your workflow still has to handle it. For a solo operator, the value is margin: a missed follow-up becomes a late follow-up, not a silent loss.

A better default still leaves you responsible for knowing which triggers touch revenue. Downtime can expose a workflow that was quietly relying on old timing habits. The audit below is the durable trick: test the restart path once, then trust the schedule with less anxiety.

Run the five-point restart-survival audit before you trust the schedule

Keep the list short enough to repeat after an upgrade. Each item should take minutes, and the result should be a note you can read later without opening the workflow. Self-hosting the instance makes the audit a margin tool. A schedule can create extra follow-ups: an invoice that did not go out, a customer who did not hear back, a billing discrepancy that needs explaining. The audit does not remove the work a schedule creates; it keeps the work from arriving all at once after downtime. It protects the hours you would spend chasing a missed run.

• List every money-trigger. Write down each scheduled workflow that sends invoices, checks billing, follows up with customers, or posts revenue. A short note is enough; the point is to see the full scope.
• Note the schedule and grace period. For each trigger, record when it should run and how long it may be late before it is considered missed.
• Read the misfire policy. Decide what happens after the grace period, make the answer explicit, and match it to the business consequence. An unclear policy leaves the workflow untested.
• Test a restart or delayed run. Stop the instance, let a scheduled run pass, then start it again. Confirm whether the late run appears, and whether the workflow behaves the way you expect.
• Remove legacy timing assumptions. Delete notes, comments, or habits that assume the old timing behavior. A workflow that needs that behavior should be marked for a deliberate configuration change instead of guessing.

Visibility comes first. You cannot judge a restart if you do not know which triggers matter, how late they can be, and what happens when they are too late. The test is the part that makes the audit real. Cleanup keeps the next audit clean. Revenue work deserves a note that survives the next upgrade, not a detail that disappears later.

Old timing assumptions are now a liability

n8n 2.45.0 removed the Skip Durable Scheduler node option and the N8N_ENV_FEAT_SKIP_DURABLE_SCHEDULER environment variable. It also removed the unused N8N_SCHEDULER_MIN_INTERVAL setting. n8n can keep the previous clock-aligned timing behavior by setting N8N_SCHEDULER_TRIGGER_NODE_MODE=legacy.

These removals are small in the release notes and large in practice. They force you to stop treating the durable scheduler as a set of hidden defaults. A workflow that depends on old behavior should have that dependency visible, named, and easy to remove later. Without that dependency, the workflow can be left alone.

Do not leave legacy mode as a quiet exception. Use it only with a note naming the workflow and the reason. Without that note, the next person who touches the instance will assume the schedule is simple, and that assumption is exactly what a restart can break.

Fix the trigger before you add another automation when a workflow fails the test. Run the audit after the upgrade, and again after any change to a schedule trigger. Keep the notes together. When a schedule misbehaves, you will know whether the problem is the trigger, the misfire policy, or a legacy assumption.