Open-source observability infrastructure for embedded systems.

Capture crashes. Preserve device state. Understand failures across firmware, hardware revisions, and real-world fleets.

offline-first   hardware-aware   self-hostable   built for constrained devices

Last State is building an open observability stack for embedded systems.

When a device crashes, resets, loses power, or disappears from the network, the most valuable evidence is often destroyed with it. Last State captures that evidence at the source: CPU context, reset causes, breadcrumbs, health metrics, firmware identity, hardware revision, and the conditions immediately surrounding a failure.

It is designed for systems where traditional software observability stops working: bare-metal firmware, RTOS devices, offline equipment, low-bandwidth networks, remote sensors, robots, industrial controllers, and connected products operating outside the safety of a data center.

The system may stop. Its last state should not disappear.

Traditional observability was built around servers and applications with abundant memory, permanent connectivity, and operating systems capable of writing logs after something goes wrong.

Embedded systems fail under very different conditions.

Last State is not only crash reporting for smaller computers. It is an attempt to make hardware-aware reliability engineering practical, open, and accessible.

flowchart LR
    A["Embedded device<br/>Latch · C + Assembly"]
    B["Persistent event<br/>Crash · reset · health · context"]
    C["Available transport<br/>UART · USB · CAN · BLE · LoRa · IP"]
    D["Relay<br/>Go · local and offline gateway"]
    E["Trace<br/>Self-hosted or managed cloud"]
    F["Issues · devices · releases<br/>Firmware and hardware correlation"]

    A --> B
    B --> C
    C --> D
    C --> E
    D --> E
    E --> F

A failure follows a simple path:

observe → capture → preserve → package → protect → queue → deliver

The device records a compact diagnostic event, persists it safely, and delivers it through whatever connection is available. A directly connected device may send over HTTPS. An offline microcontroller may wait for a UART or USB relay. A remote LoRa node may transmit only a small incident beacon and preserve the full dump for later collection.

Connectivity is a transport choice, not a product requirement.

The components are designed to work together, but not to create lock-in. A device can be analyzed locally, sent to a self-hosted Trace deployment, or connected to the managed Last State cloud.

Last State is being designed to preserve the context engineers normally lose during a reboot:

• CPU exceptions, fault registers, stack context, and reset reasons;
• breadcrumbs describing the final execution path;
• battery, voltage, temperature, memory, timing, and device-health metrics;
• firmware version, immutable build identity, bootloader, and release state;
• PCB revision, BOM revision, manufacturing batch, and product variant;
• RTOS task state, stack exhaustion, watchdog checkpoints, and failed assertions;
• I²C, SPI, UART, CAN, USB, storage, network, and power-related failures;
• explicitly approved stack or memory regions for deeper diagnostics.

Sensitive memory is excluded by default. Full dumps are opt-in, bounded, and subject to redaction policies.

A device does not need Wi-Fi, TCP/IP, TLS, DNS, or even a valid wall clock. Events can remain on the device, move through a local Relay, or be exported as files for completely disconnected analysis.

The crash path avoids heap allocation, blocking calls, network operations, complex filesystems, and unnecessary application dependencies. Architecture-specific Assembly preserves the CPU state; portable C interprets and persists it.

Failures can be compared across firmware builds, PCB revisions, BOM changes, manufacturing batches, power conditions, peripherals, and device cohorts. The goal is not only to show where software stopped, but to reveal why this hardware failed here.

Every subsystem is modular and compile-time configurable. A constrained MCU can include only minimal crash capture and UART delivery. Larger systems can add breadcrumbs, persistent queues, coredumps, cryptographic identity, health reports, and multiple transports.

The device SDK, protocol, collectors, and self-hosting path are central to the product—not an afterthought. Managed hosting should provide convenience, scale, operations, and collaboration without making the diagnostic data inaccessible outside the platform.

The first public milestone is called First Trace:

STM32 Cortex-M
    ↓
intentional HardFault
    ↓
Assembly preserves the exception context
    ↓
C stores the crash across reset
    ↓
UART delivers the event
    ↓
Go Relay receives and validates it
    ↓
the exact function and source line are reconstructed

The milestone is complete when a real board crashes and Last State can report:

HardFault in sensor_read()

Source:    src/sensor.c:142
Firmware:  0.1.0 · build 8f74b2
Hardware:  Rev B
Reset:     precise data bus fault
State:     3.21 V · 71 °C · 8.2 KB free heap

No dashboard can substitute for this proof. The product begins with reliable capture on real hardware.

The long-term goal is a complete reliability layer for embedded products.

Last State should help engineers discover that a brownout began after a regulator substitution, that a watchdog affects only one firmware release, that a sensor failure clusters around a manufacturing batch, or that a crash appears exclusively under a specific temperature and hardware revision.

That means bringing together:

firmware state
+ processor state
+ physical conditions
+ hardware identity
+ fleet-level evidence

The result is observability that crosses the boundary between software and the physical system it controls.

Last State is intended for embedded developers, hardware teams, robotics projects, IoT startups, research laboratories, industrial systems, open-hardware communities, and anyone responsible for devices that fail far away from a debugger.

It should remain useful whether the fleet contains one prototype on a workbench or thousands of devices in the field.

On-device runtime     C11 + architecture-specific Assembly
Relay and gateways    Go
Cloud control plane   Go
Crash processing      Go, with Rust for specialized parsers when justified
Web and documentation TypeScript + MDX
Metadata              PostgreSQL
Artifacts             S3-compatible object storage

The architecture favors clear boundaries, portable components, reproducible builds, and measurable performance over unnecessary complexity.

1. Never lose the first useful failure.
2. Never require a network to capture evidence.
3. Never trust an event merely because a device sent it.
4. Never collect arbitrary memory by default.
5. Never hide the protocol behind the cloud.
6. Never trade reliability for a more impressive architecture diagram.
7. Measure footprint, latency, storage wear, and failure behavior on real hardware.

Last State is an early-stage open-source project under active development. APIs, protocol details, repository boundaries, and deployment architecture may evolve before the first stable release.

The immediate focus is narrow by design: prove dependable crash capture on Cortex-M, then expand one architecture, transport, and operating environment at a time.

We are interested in engineers and researchers working with:

• ARM Cortex-M and RISC-V exception handling;
• bare-metal systems, FreeRTOS, Zephyr, and ESP-IDF;
• ELF, DWARF, coredumps, and source-level symbolication;
• persistent storage under brownout and power-loss conditions;
• low-bandwidth transports such as CAN, BLE, and LoRaWAN;
• embedded security, device identity, redaction, and secure elements;
• hardware-in-the-loop testing and fault injection;
• developer experience, documentation, and self-hosted infrastructure.

The best contributions begin with a real failure mode, a reproducible test, and evidence that the proposed solution works on actual hardware.