Where Heapwatch Came From

Heapwatch was not planned as a product. It started as internal tooling inside Remoted, our GPS and vehicle tracking service, where ESP32 hardware ran in vehicles and machines a long way from anybody's desk.

Those boards behaved perfectly on the bench. Out in the field they would run for days and then reboot on their own. Nothing we could reach explained it, and reproducing it at the desk with a cable attached was hopeless, because the conditions that caused it only existed out there: real power, real temperature, real network, real weeks of uptime.

So we stopped waiting for the device to come back to us. We streamed what we actually needed off it while it was still running, and when a board panicked we had it save a core dump to flash and upload it on the next boot, then decoded that dump against the exact firmware build it crashed on. The ghost reboots stopped being ghosts. They became a file and a line number.

That tooling turned out to be the part we could not work without, so we built it properly and made it available to everyone else debugging the same class of problem.

The Decisions That Shape It

Heapwatch is a workbench, not a status dashboard. Everything in it comes from a specific frustration we had while shipping firmware:

Once per second, not once per minute. Fleet monitoring samples slowly because it only needs to know a device is alive. Catching a slow leak, a fragmenting heap, or a task running out of stack needs far more resolution than that, so we capture every second and keep millions of points.
A crash has to decode itself. A core dump without the matching ELF is a wall of hex. Heapwatch keeps the build that was running on that device, so a panic arrives as a file, a line, and a call stack you can read.
No cable for the ordinary things. Reading a log file, changing a config value, pushing new firmware: none of that should mean unscrewing a device out of a machine and carrying it back to a desk.
Your AI agent needs the same evidence you do. Our MCP server hands live state, full history, and decoded crashes straight to Cursor, Claude Code, or whatever you use, so the agent debugs from facts instead of guessing from a prompt.

Who We Build For

Engineers and teams writing ESP-IDF firmware for ESP32-family devices. Development boards on the bench, soak racks running for weeks, pilot units already bolted into a machine at a customer site: anywhere the device is doing something you cannot watch over a serial cable.

It fits the part of the job where the firmware is still changing and the hard bugs have not been found yet. That is the phase where guessing is most expensive and where evidence is hardest to get.

What Heapwatch Is Not

It is not a general-purpose IoT device manager, and it does not replace whatever platform already runs your production fleet. We deliberately kept it pointed at firmware development and diagnostics rather than trying to be everything at once.

Remote config, remote files, and OTA exist here because they save a trip to the hardware during development, not as a factory provisioning system. We also do not pretend an OTA cannot brick a board, which is why those actions are restricted to devices you have marked as development, testing, or staging, and why our Terms say plainly where that risk sits.

Heapwatch tells you what your firmware did. It does not promise to find every defect, and the engineering calls stay yours.

Talk To Us

Questions about how Heapwatch fits your hardware, your build setup, or your team? Write to info@heapwatch.com or use the contact page. If you would rather just try it, the trial runs for 10 days and does not ask for a card.