Logs are time-ordered streams of diagnostic data emitted by Fuchsia programs. They most commonly take the form of human-oriented text strings describing changes to state in a subsystem.

See Recording for information about how Fuchsia software writes logs.

See Viewing for information about how to view the recorded logs.

See Attributing LogSink connections for information about how Fuchsia identifies the producer of each log message.


Log records have a few pieces of metadata, mostly self-reported by the programs that generate the logs. At minimum, messages have a timestamp and string contents.

If a message is written to the LogSink protocol it also has a severity, a PID, a TID, a count of prior dropped logs, and a list of string tags.

Unless a component's parent realm provides its own LogSink, diagnostics also includes trusted SourceIdentity metadata for incoming log connections. This information is used to provide a default tag for messages without tags.


Currently all log stores are rotated on a first-in-first-out (FIFO) basis, with newer messages overwriting older ones. Messages from any component can roll out messages from any other component. There is currently very limited tracking of when messages are rolled out of their buffers.


There are two in-memory stores for logs on a Fuchsia device:

Note: If you can't find some logs, see Recording logs to find out which of these buffers is the intended point of transit for your message. See Viewing logs once you know the location.


The feedback data component maintains a persistent disk store of messages from the previous boot. These messages appear when running fx snapshot.