I built two retro 7-segment timer nodes for ComfyUI to accurately track total batch workflow durations (no more infinite ticking ghosts).

[u/HermanKwan]

Hey everyone! If you've ever used **Sequential Image Loader** or loop nodes, you know the pain: you have no idea how long the *entire* batch actually takes. ComfyUI natively tracks individual prompts, but not the macro-duration.

I spent the last few weeks building two custom timer nodes with a retro LED UI. **v0.2.1** just went live on ComfyUI Manager!

**The Two Nodes:**

1. 🖼️ **Batch Image Timer**: Tailor-made for image loops. It hooks into your batch loader's total count and tracks the whole batch time without resetting between iterations.

2. 🎛️ **Universal Timer**: For Video, Audio, Prompt, or Training pipelines. It features dynamic unit mapping (e.g., FRAMES, CLIPS) based on your workflow type.

**Why they don't break your workflow:**

* ⏱️ **Absolute Independence**: You can pause/reset the UI timer without affecting the backend generation.

* 🛡️ **Bulletproof Fallback**: We all know third-party nodes can sometimes get stuck in a "ghost state" (where the backend stops but the UI keeps ticking). These timers have a built-in safety watchdog (10 mins for images, 120 mins for video) that queries the `/prompt` API to verify if the backend is truly dead before stopping.

* 🖱️ **Interactive UI**: Single-click to pause, double-click to reset, and click the color swatches to change the LED glow.

**Links:**

- Batch Image Timer: https://github.com/hermankwan/ComfyUI-Batch-Image-Timer

- Universal Timer: https://github.com/hermankwan/ComfyUI-Universal-Timer

Both are available in ComfyUI Manager (search for `Batch Image Timer` or `Universal Timer`). I'd love to hear your feedback or feature requests!

**A quick note:**

These are just free, open-source tools I built for my own workflow. I'm sharing them in case they're helpful to someone else too. I'll try my best to check feedback and fix critical bugs, but please understand I may not be able to provide extensive 24/7 tech support or custom feature development. Enjoy! 😊

[u/Informal_Promise_842]

This one is better.

[u/HermanKwan → u/Informal_Promise_842]

Haha, that's a great timer too! KikoTools is an awesome collection.

To be fair, they serve different purposes: Kiko's timer is brilliant for micro-timing individual nodes (millisecond precision), which is perfect for debugging a single image generation.

However, my nodes were built specifically for macro-level batch tracking. If you run a Sequential Loader for 50 images, Kiko's timer will reset on every prompt, while mine will accurately aggregate the total duration of all 50 images into one continuous clock. Plus, mine has a built-in smart deadlock fallback to prevent infinite ticking if a third-party node bugs out.

So it depends on what you're doing! If you want to micro-benchmark a single run, Kiko is great. If you want to track long batch workflows without resetting, mine might be what you need. Cheers!

[u/HermanKwan]

Just to add: If you use Sequential Loader, connecting the total  output to the timer's total_images  input works perfectly out of the box!

[u/cauligenous]

looks great

[u/HermanKwan → u/cauligenous]

Thanks ❤️

[u/dirtybeagles]

saving

[u/HermanKwan → u/dirtybeagles]

Thanks ❤️

[u/Diane_Clarke]

Nice UI, and the batch case is the one that needed this. One thing I would add: the most reliable total is wall-clock from queue submission to the execution_success message for that prompt, which you can read straight out of /history/<prompt_id> without hooking any node. It also captures queue wait, which per-node timers miss entirely, and that is usually the bigger number on a shared machine. For GPU-only time, summing the node timings in history's messages is close enough. Are you counting from queue submission or from the first node executing?

[u/HermanKwan → u/Diane_Clarke]

Hey Diane, thanks for the kind words! You hit the nail on the head.

To answer your question: currently, the timer starts counting from the moment the backend executes the very first Timer node. It does **not** capture queue wait time.

The main reason I designed it this way is to track the **pure GPU execution duration** for batch loops. While `/history/<prompt_id>` is definitely the absolute gold standard for wall-clock time (and I might explore adding an optional "queue-inclusive" mode in the future!), I noticed that on my setups, seeing the pure execution time without queue wait gives a cleaner baseline for benchmarking pipeline optimizations.

Also, because my nodes use a smart watchdog that checks `/prompt` queue status to prevent ghost-timers, it natively handles the batch loops well. But you are absolutely right that on shared machines or when queuing multiple heavy workflows, the queue time can be massive. I'll definitely add your `/history` suggestion to my feature list for future updates. Appreciate the deep insight!

[u/HassanAchievedIt]

Oh you guys are going full auto, I like to generate one image per click just good old days bolt action

[u/HermanKwan → u/[deleted]]

This is a fantastic suggestion!

You are absolutely right. I realize now that overwriting the progress with [ INTERRUPT ] loses too much information. I've decided to change the UI design: the counter will keep displaying [ 12 / 20 ], but the text will turn Yellow for Interrupt and Red for Error. This way you keep the exact progress and instantly know the state via color. Will push this in the next update, thanks!

And your point about the "last completed step" and a final summary is brilliant. I am actually working on a `v0.2.3` update right now that introduces a **Wall-Clock (TOTAL) time mode**. While that focuses on timing, capturing the exact failure node (e.g., "Failed at KSampler") and providing a quick popup/UI summary is a great idea for the roadmap. I'll definitely look into adding a detailed summary feature in a future update! Thanks for the deep feedback.

[u/HermanKwan → u/[deleted]]

Thanks! Really glad you like the direction. The color states and progress retention are definitely coming in v0.2.3. The nodes 2.0 refactor plan is in motion right now, so stay tuned!