Troubleshooting

Most reports about this node turn out to be deliberate, documented design decisions meeting an understandable expectation. Each entry below is symptom-first: find what you're seeing, read what's actually happening. If your symptom isn't here, the last section explains what to include when asking for help.

"The count dropped on its own — no message arrived"

You are in sliding mode, and this is its defining behavior: each counted message ages out individually, so the count decays as messages fall out of the window. Nothing is wrong. If you expected the count to only ever grow until a trigger or a single expiry, you want fixed mode. Read Window Modes — it is the one page that prevents most surprises with this node.

"The count decayed but no event fired"

Correct: intermediate decay is silent by design. Only decay to zero — the last live message aging out — emits windowexpired, because that is the counting → idle transition. A per-decay event on a noisy sensor would flood output 3 with low-value traffic. The decaying count is observable three ways: the status label, a query, or a Heartbeat tick.

"The Trigger output went silent"

Almost always one of two gates:

• Cooldown — after a Trigger, counting is blocked for the configured cooldown period. Every blocked message appears on output 3 as counted / ignored: true, and output 1 stays silent by guarantee. See Cooldown.
• Disabled — the disable command blocks counting in any state. Same ignored: true signature on output 3, with disabled: true in the envelope.

A query tells you instantly which: check timerState for "cooldown" and the disabled flag. Note that the disabled flag survives restarts when persistence is on — a node disabled last week and never re-enabled is a classic "why is it dead" cause.

"reset / enable didn't cancel the cooldown"

By design, only stop cancels a cooldown. reset bounces off (ignored: true); enable toggles the disabled flag but the cooldown holds — they are independent blocking conditions. A cooldown is a protection mechanism, so the commands that routinely fly around flows can't release it by accident. See Cooldown.

"It never triggered, even though three events arrived close together"

If you're in fixed mode: the window anchors to the first message of a cycle. A cluster that straddles a window boundary — two events late in one window, one early in the next — never accumulates to the limit. This is fixed mode's documented blind spot, with a worked timeline on Window Modes. Sliding mode exists precisely to detect "N events within any Y-long span."

"Fewer counted events than I expected"

The message that completes the count emits only triggered, not an additional counted — so a full cycle produces limit − 1 counted events plus one Trigger. If you're tallying activity from output 3, count both event types. See Events.

"My message was swallowed as a command"

Any payload equal to one of the seven command strings — stop, reset, query, disable, enable, setcountlimit, setwindow, in any letter case — is treated as that command and never counted. A sensor that happens to emit the string stop will stop your cycle instead of counting. If your data can collide with command words, normalize it upstream (a change node mapping it to something else, or moving the value out of msg.payload).

"It didn't trigger after a restart, even though the count was already at the limit"

By guarantee, a restore never fires the Trigger — even if the persisted count meets the limit. Triggers only ever fire on a live counted message; the next candidate after the restore completes the count and fires. Likewise a restore emits no events at all — no counted replays, no retroactive windowexpired. See Persistence.

"After a restart, the window expired a few seconds later than it should have"

If a fixed window (or cooldown) had less than 3 seconds remaining at restore time, the node randomizes the remainder to 3–8 seconds — an anti-flood rule that stops many nodes from firing simultaneously the instant Node-RED comes up, and gives the rest of your flow time to initialize. Documented, with rationale, on Persistence.

"The node ignores the values in its edit dialog"

Check for runtime overrides: setcountlimit and setwindow change the effective values, which govern all future cycles — and survive restarts when persistence is on. A query shows the effective countLimit and windowDuration; if they differ from the dialog, something in your flow sent a set command. A redeploy resets to the dialog values only when persistence is off. See Examples: Runtime Commands.

"Persistence stopped working after I exported and re-imported the flow"

Re-importing assigns the node a new ID, and the state file is keyed by node ID — the new node cannot find the old node's file. The stale file is harmless (it will never be read) but the prior state is not recoverable. See Persistence.

"Heartbeat isn't ticking"

The heartbeat runs only while a cycle is active — counting or cooldown — and is silent while idle. If you need a liveness signal regardless of state, an inject node sending query on an interval is the supported equivalent. Also confirm the interval isn't 0 (disabled). See Heartbeat.

Asking for help

If none of the above matches, post in the project's Discussions (Q&A) or, for something reproducible, open an Issue. Either way, include:

• Your node configuration — especially the Window Mode. Fixed and sliding behave very differently, and most puzzles dissolve once the mode is known.
• The debug output from output 3 (Events), with the complete msg object (set the debug node to "complete msg object"). The envelope — timerEvent, ignored, source, timerState, count — almost always names the cause, and it lets others help without guessing.
• What you expected to happen, and what happened instead, with rough timings if the window or a cooldown is involved.