Know why your devices crash in the field.
Symbolicated firmware backtraces, reboot reasons, and fleet health - from a few KB of device code. It's crash reporting for the hardware you can't reach.
- Proven on real silicon
- Server-side symbolication
- Bring your own transport
- 0app_tick @ src/work.c:58# null deref → cfg->retries
- 1do_work @ src/work.c:131
- 2app_main @ src/main.c:84
- 3vPortTaskWrapper @ freertos/port.c:142
- +1.204sjoined ap rssi=-61
- +3.880sheap_free=41208
- +4.012sfetch config build=a3f9c7e1
- +4.013sGuru Meditation: LoadProhibited
A device crashes in the field. Then what?
Today you get a reboot - maybe a garbled serial log, if someone happens to be plugged in. No stack trace. No fleet view. No way to tell if it's one unit or ten thousand. Reproducing a field fault is misery, and firmware teams are flying blind on exactly the failures that matter most: the ones in production, on hardware they can't reach.
Just a reset reason, if you're lucky.
One unit or ten thousand? No idea.
It only fails on the bench you don't have.
Four steps from fault to fix
The on-device SDK is tiny and the ingest path is deliberately dumb. All the heavy lifting happens server-side.
Device SDK
A few KB of C on the device captures the crash, reboot reason, metrics and logs. Bring your own transport - WiFi, LTE, Ethernet, mesh.
Ingest
A stateless endpoint accepts opaque chunks and acks fast. No per-device state, no cleverness - that's the point.
Server worker
Decodes, dedupes and reassembles coredumps byte-perfect, then groups recurring faults into Issues.
Symbolicator → dashboard
Build-id-keyed ELF turns addresses into function @ file:line, surfaced in a real-time fleet dashboard.
Built for firmware, not retrofitted from web
Real symbolicated crashes
The server turns a coredump - or a tiny on-device backtrace - into function @ file:line, grouped into Issues with the offending build, affected devices, occurrences and the breadcrumbs leading up to the fault. You see where and why, not just that.
Economical at fleet scale
The on-device SDK is tiny and the ingest path is deliberately lightweight and stateless - all the heavy lifting lives server-side. Designed so watching a large fleet doesn't get in the way.
Truly hardware-agnostic
One wire contract; the same SDK runs across chips and transports. ESP32 (ESP-IDF and Arduino) is proven on real hardware; RP2040 is next. Any MCU/RTOS/Linux target is additive - not a rewrite.
From null-pointer to function @ file:line - automatically
A real ESP32-S3 crash, captured and symbolicated end-to-end with no human in the loop. This is the artifact a firmware engineer actually trusts.
Also proven without a full coredump: an Arduino-ESP32 fault captured with a minimal on-device backtrace resolves to the exact deep_fault → do_work → app_tick chain.
- 0app_tick @ src/work.c:58# null deref → cfg->retries
- 1do_work @ src/work.c:131
- 2app_main @ src/main.c:84
- 3vPortTaskWrapper @ freertos/port.c:142
- +1.204sjoined ap rssi=-61
- +3.880sheap_free=41208
- +4.012sfetch config build=a3f9c7e1
- +4.013sGuru Meditation: LoadProhibited
One wire contract. Your silicon next.
ESP-IDF + Arduino
LiveRaspberry Pi Pico
LiveCortex-M
LiveBLE + Thread
In progressGet early access. Shape the roadmap.
We're onboarding a founding fleet of firmware teams. Early access, direct line to the build, and a say in which targets land next.
Email only. No spam - just launch news and the occasional question about your stack.