> Any concerns about privacy? Even if Memfault is one-way (as you mentioned in a different comment), that doesn't mean that important user information is not ex

> Any concerns about privacy? Even if Memfault is one-way (as you mentioned in a different comment), that doesn't mean that important user information is not exposed. Battery SOC and last-seen stats aren't completely harmless. Yes - some of the data is sensitive. We encrypt the data, use an aggressive expiry policy (2 weeks by default), and work with our customers to limit PII. Memfault does not know who the end user of the device is. > Maybe this will be clearer when you release docs on the SDK - do you provide interfaces for normal logging in addition to just crash logging? Ideally, firmware applications should never crash, but unexpected logic states or invalid user input happen all the time. Currently, we provide APIs for data logging ('telemetry') and error logging. Note that errors do not have to be crashes. You can send Memfault a trace for user defined issues (e.g. "bluetooth failed to connect") or even no issue at all. > How are you expecting licensing to work? Per device? Monthly subscription fee? Flat fee software purchase? It's a monthly subscription fee (not per device). > Are your libraries ASIL or FDA certified to allow use in the automotive or medical industries? What are the reliability/safety implications of wrapping your main binary in Memfault's monitoring interface? We are not currently certified, but this is something we know we'll have to do. Our error reporting only runs when an error is encountered, not during normal operation. Our telemetry collection can run on a timer, and a bug in our code there could impact your device.