Health Check (Internal)

Search your node menu for "Health Check (Internal)" and you'll find a node with zero inputs, zero outputs, and nothing to wire. Drag it into a graph and it returns an empty tuple and goes back to sleep. That's because HealthCheckDummy was never meant to do anything in a workflow - it's the registration token for a pack whose real job happens before you even see the UI.

What it actually is

HealthCheckDummy is the dummy node inside ComfyUI HealthCheck (love530love/ComfyUI-HealthCheck, currently v1.0.9). The pack is a startup monitor: when ComfyUI boots, it captures the startup log, counts your custom nodes, detects which ones failed to import, and prints a big ANSI-colored "Plugin Health Report" to the console with a health percentage.

Why the dummy node exists is the clever bit. ComfyUI marks a custom node pack as "IMPORT FAILED" when its module raises during import. A health-check plugin that itself trips the import failure checker would be embarrassing, so the pack registers this inert node to announce "I loaded fine," and does its real work as a side effect of importing.

How it works

At import time the pack starts a LogCapture that patches every logging.Handler.emit, installs a watcher thread to catch handlers ComfyUI adds later, and tees stdout/stderr - a belt-and-suspenders setup that covers both the print() path and the logging path (the comments in the source explicitly note this handles pre- and post-v0.27.0 ComfyUI).

It watches the captured stream for three landmarks: "Import times for custom nodes:", "To see the GUI go to:", or "[ComfyUI-Manager] All startup tasks have been completed." Each triggers a delayed report - up to 15 seconds for the GUI marker, so async plugin initialization finishes first - and if nothing fires, a 60-second backup timer forces the report anyway.

The report itself is genuinely useful: it counts plugins (folders plus standalone .py files) in your custom_nodes directory, pulls the node-class total from nodes.NODE_CLASS_MAPPINGS, and scans the captured lines for IMPORT FAILED to list exactly which plugin failed and its full path, ending with the hint to search the log for Traceback, ModuleNotFoundError, or ImportError.

The inputs and outputs that matter

There aren't any. info_schema is empty on both sides, and execute() returns nothing. This node is never a step in your workflow - it's the pack's proof of life. If you see it in the node list, the pack loaded and the health report is already in your console. Forget it exists and go about your day.

How to install it

The pack has no dependencies at all - requirements.txt is pure standard library, so no pip installs, no model downloads, no config. Any of these work:

# ComfyUI Manager: search "HealthCheck" and install
# or
cd ComfyUI/custom_nodes
git clone https://github.com/love530love/ComfyUI-HealthCheck.git

Or skip git entirely: grab ComfyUI_HealthCheck.py from the Releases page and drop it straight into custom_nodes/. Then restart ComfyUI and watch the console - you'll see the banner and health report a few seconds after the server finishes starting. Works on Windows, Linux, and macOS with Python 3.8+.

Common issues

You don't see the banner. First check that ComfyUI actually loaded the pack - if HealthCheckDummy isn't in your node list, the pack's own import failed and you've got a bigger problem. Given it's stdlib-only, that would be an odd install, not a bug.

The health percentage looks wrong. It's an honest approximation: the "total plugins" count is just directory and .py entries under custom_nodes, not a verdict on each one, and "failed" is derived only from IMPORT FAILED lines caught in the capture window. A node that imports fine but crashes later, or a plugin that fails after the 15-second timer fires, slips through. Treat the number as "did ComfyUI load cleanly," not a deep audit.

Something actually is failing. This is the one where the pack earns its keep: instead of scrolling past a wall of tracebacks, you get the failed plugin's folder name and full path printed right there. The fix is the same as it's always been - that ModuleNotFoundError at the top of the traceback is your answer, usually a missing requirement or a dependency conflict, which is the ecosystem's oldest pain point. The pack just tells you where to look instead of making you hunt.

It's a thin utility, but if you run 300+ custom nodes - the README's own example counts 320 - the five seconds it saves you every boot add up fast. Just don't expect it to fix anything for you.