TL;DR:

  • Memfault provides crash reporting, device metrics, remote logging, and OTA firmware updates for embedded/IoT devices — the observability stack that firmware teams have historically lacked.
  • The SDK is C-based with platform ports for nRF5 SDK, Zephyr, FreeRTOS, Linux, and Android; integration time is typically a few days.
  • The core value is in production: you learn what’s actually failing in deployed devices rather than waiting for support tickets.

Web developers debug production with Sentry or Datadog. Mobile developers have Firebase Crashlytics. Firmware teams have historically had neither — when something goes wrong in a deployed device, you typically find out through support tickets, device returns, or manual log pulls that require physical access.

Memfault is built specifically to close that gap. It provides the crash reporting, metrics, logging, and OTA update pipeline that embedded teams need without requiring significant firmware rearchitecting to adopt.

What Memfault Captures

Coredumps: When a device crashes, Memfault captures a coredump — a snapshot of registers, stack contents, and configurable RAM regions at the moment of fault. Back in the Memfault console, this is decoded into a symbolic stack trace using the ELF file from your build. You see the exact line of code that caused the fault, the local variable values, and the call chain that led there.

Reboot reasons: Every device restart is logged with a reason (power cycle, watchdog, assert, low battery, OTA update) and associated metrics. Over a fleet of devices, abnormal reboot rate is often the first signal of a firmware issue before crashes start appearing.

Custom metrics: Time-series metrics you define — RSSI, battery voltage, sensor readings, queue depths, heap free, uptime — are uploaded periodically and aggregated in the console. You can set alert thresholds and chart fleet-wide distributions.

Traces and logs: Structured log events (not free-form text, to keep payload sizes small) that you can query across the fleet. Useful for correlating events leading up to a crash, or monitoring specific state transitions.

Heartbeats: Regular health check-ins that confirm a device is alive and within expected operating parameters. A device that stops heartbeating generates an alert.

SDK Integration (Zephyr Example)

Memfault distributes its SDK through its own repository and as a Zephyr module. On Zephyr, integration follows the standard module pattern:

# west.yml — add Memfault as a project dependency
manifest:
  projects:
    - name: memfault-firmware-sdk
      url: https://github.com/memfault/memfault-firmware-sdk
      revision: latest
      path: modules/lib/memfault-firmware-sdk
// main.c — initialise Memfault at boot
#include "memfault/core/build_info.h"
#include "memfault/core/platform/device_info.h"
#include "memfault/ports/zephyr/http.h"

// Required: provide device info so Memfault knows what it's talking to
void memfault_platform_get_device_info(sMemfaultDeviceInfo *info) {
    info->device_serial = get_device_serial_from_nvs();
    info->software_type = "main-app";
    info->software_version = APP_VERSION_STRING;
    info->hardware_version = HW_REVISION;
}

// At boot: initialise and start the periodic chunk upload task
memfault_zephyr_port_install_root_certs();
memfault_zephyr_port_http_periodic_upload();

The SDK uses a “chunk” abstraction — data is packetised into small chunks that can be uploaded over whatever transport is available (HTTPS, MQTT, BLE to a gateway, or even stored offline for later upload). This makes it work on constrained devices with unreliable connectivity.

// Custom metrics — define in memfault_metrics_heartbeat_config.def
MEMFAULT_METRICS_KEY_DEFINE(battery_pct, kMemfaultMetricType_Unsigned)
MEMFAULT_METRICS_KEY_DEFINE(rssi_dbm, kMemfaultMetricType_Signed)
MEMFAULT_METRICS_KEY_DEFINE(queue_depth, kMemfaultMetricType_Unsigned)

// In your application code
MEMFAULT_METRIC_SET_UNSIGNED(battery_pct, battery_get_percent());
MEMFAULT_METRIC_SET_SIGNED(rssi_dbm, wifi_get_rssi());

At the configured heartbeat interval (typically 1 hour), these values are captured and queued for upload.

OTA Firmware Updates

Memfault’s OTA system has two parts: the release management interface in the console, and the OTA client in the device SDK.

Releases: You upload firmware binary files and ELF debug symbols as a release. Releases can be targeted by hardware version, software version, cohort (a group of devices you define — “beta testers”, “production-region-EU”), or individual device serial.

Delta updates: Memfault supports delta OTA — the device downloads only the diff between its current firmware and the target version, rather than the full binary. For devices on constrained cellular connections, this can cut update data from 500kB to 50kB.

Rollout controls: Percentage rollout lets you push an update to 5% of a cohort, monitor for increased crash rates or failed reboots, and then expand or roll back. The console shows a side-by-side view of crash rate and reboot reason distribution for updated vs non-updated devices.

// OTA check — typically run at boot or on a scheduled interval
sMfltHttpClientConfig http_cfg = {
    .api_key = MEMFAULT_PROJECT_API_KEY,
};

eMfltHttpOtaResult r = memfault_http_client_get_latest_release(&http_cfg, &release);
if (r == kMfltHttpOtaResult_UpdateAvailable) {
    // Download and apply the release
    memfault_http_client_download_ota_release(&release, ota_write_callback);
}

The Coredump Experience

The console’s coredump analysis is where the product earns its keep. A typical flow:

  1. Device crashes in production (a customer reports the device stopped working)
  2. Memfault receives the coredump on the next successful connectivity window
  3. In the console: Issues tab shows a new issue, grouped with any other devices that crashed at the same location
  4. Open the issue: see the symbolic stack trace decoded from your ELF, local variables, heap stats, and the trace events leading up to the crash
  5. The coredump includes a “similar issues” view — other stack traces that may share a root cause

For teams that previously relied on customers returning devices for forensic analysis, or that had no post-crash visibility at all, this alone justifies the integration cost.

Platform Support

  • Nordic nRF5 SDK and nRF Connect SDK (Zephyr-based)
  • Zephyr RTOS (generic, works with any Zephyr-compatible MCU)
  • FreeRTOS (ESP-IDF, generic ARM)
  • Mbed OS
  • STM32 with CubeIDE
  • Linux (for embedded Linux devices — Raspberry Pi, iMX8, BeagleBone)
  • Android (for device makers building custom Android hardware)

For MCUs not on this list, the SDK provides a platform abstraction layer with documented porting requirements — typically a few days of work if you’re familiar with your platform’s memory and interrupt model.

Pricing and Limits

Memfault’s pricing is device-based — you pay per monthly active device (a device that has uploaded at least one chunk). The free Developer tier covers 100 devices, which is enough for prototyping and small pilot deployments.

Production tiers start at a per-device-per-month rate with volume discounts. The Memfault pricing page has a calculator, but for context: teams with fleets in the thousands typically land in the range where the cost is measured in cents per device per month — easily justified against the cost of a single device recall or a field service call.

Alternatives and Comparison

Particle Device Cloud: Strong on cellular-connected devices, particularly Particle’s own hardware. Includes OTA but observability tooling is thinner than Memfault.

AWS IoT Device Management + CloudWatch: More configurable, scales to very large fleets, but requires significant setup work to replicate what Memfault provides out of the box. Better suited to teams already deeply invested in AWS infrastructure.

Self-built with InfluxDB + Grafana + custom OTA: Some teams build their own. The result is often good for metrics but weak on crash forensics — symbolic stack trace decoding from coredumps is genuinely difficult to rebuild well.

Memfault’s advantage is that it was designed specifically for embedded teams by people who came from embedded backgrounds. The tradeoffs around payload size, battery impact of periodic uploads, and constrained connectivity are built into the product rather than bolted on.

For any team shipping connected devices and expecting to maintain them in production over months or years, the integration investment pays off in the first real production incident it helps you diagnose.