enlightened@chromium.org chromeos-hardening@google.com Indicates the status of the developer switch on Chrome OS hardware. The developer switch allows users to run their own code on the device. Warning: this histogram was expired from 2022-04-03 to 2023-11-15 ; data may be missing. enlightened@chromium.org chromeos-hardening@google.com On Chrome OS hardware, indicates whether flash write protection is enabled for the {FirmwareType} firmware. Warning: this histogram was expired from 2022-04-17 to 2023-11-15 ; data may be missing. enlightened@chromium.org chromeos-hardening@google.com Indicates the status of the hardware write protect switch on Chrome OS hardware. The write protect switch protects firmware from being rewritten. Warning: this histogram was expired from 2021-09-05 to 2023-11-15 ; data may be missing. chenyian@google.com cros-hwsec-userland-eng+uma@google.com Each sample is the status code when Chaps needs to reinitializing token. chenyian@google.com cros-hwsec-userland-eng+uma@google.com Each sample is the return value of a chaps session "{Operation}" operation. The return code is defined in pkcs11 specification. There is exactly one sample logged for every chaps session "{Operation}" operation. chenyian@google.com cros-hwsec-userland-eng+uma@google.com Each sample is the return value of a chaps token manager load token operation. There is exactly one sample logged for every call to SlotManagerImpl::LoadToken(). chenyian@google.com cros-hwsec-userland-eng+uma@google.com Each sample is the return value of a chaps token manager unload token operation. There is exactly one sample logged for every call to SlotManagerImpl::UnloadToken(). chenyian@google.com cros-hwsec-userland-eng+uma@google.com Each sample is the TPM Availability status. hcyang@google.com cros-odml-foundations-eng@google.com The number of groups generated by the clustering engine that are greater than or equal to the required group size for coral feature (4 currently). This is recorded everytime the clustering engine finishes the clustering process successfully. hcyang@google.com cros-odml-foundations-eng@google.com The number of items in each cluster, generated by the clustering engine. This is recorded everytime the clustering engine finishes the clustering process successfully. hcyang@google.com cros-odml-foundations-eng@google.com The number of input items in the Group request when it reaches the clustering engine. This is recorded everytime the clustering engine starts processing a Group request. hcyang@google.com cros-odml-foundations-eng@google.com Whether the embedding cache is hit for each item in the Group request to the coral service. This isn't recorded during PrepareResource or CacheEmbeddings calls because what we care about is how frequent the cache is hit when the user-facing feature is triggered (which issues a Group request). This is recorded when embedding engine is processing each entity in a Group request and checks whether it is present in the embedding cache database. hcyang@google.com cros-odml-foundations-eng@google.com The number of embedding vector entries persisted in the on-device database. This is recorded everytime the database is initialized, which is everytime a primary user session starts (i.e., a user logs in as primary user). hcyang@google.com cros-odml-foundations-eng@google.com The number of input items in the Group request filtered out by the embedding engine. There could be multiple reasons an item is filtered, including unsupported language or safety violation. This is recorded everytime the clustering engine starts processing a Group request. hcyang@google.com cros-odml-foundations-eng@google.com Whether the language detection result cache is hit for each item in the Group request to the coral service. This isn't recorded during PrepareResource or CacheEmbeddings calls because what we care about is how frequent the cache is hit when the user-facing feature is triggered (which issues a Group request). This is recorded when embedding engine is processing each entity in a Group request and checks whether it is present in the embedding cache database. hcyang@google.com cros-odml-foundations-eng@google.com Whether the language detection result for each item in the Group request is a supported language. This is recorded when embedding engine is processing each entity in a Group request and checks whether the language is unsupported and needs to be discarded. hcyang@google.com cros-odml-foundations-eng@google.com Whether the embedding model is already loaded when coral service receives a Group request. This isn't recorded during PrepareResource or CacheEmbeddings calls because what we care about is how frequent the model needs to be loaded when the user-facing feature is triggered (which issues a Group request). This is recorded when embedding engine is processing a Group request and reaches the step that it needs to check whether the model is already loded. hcyang@google.com cros-odml-foundations-eng@google.com The safety verdict for each item in the Group request. This is recorded when embedding engine is processing each entity in a Group request and checks whether the safety check doesn't pass and needs to be discarded. hcyang@google.com cros-odml-foundations-eng@google.com Whether the safety verdict cache is hit for each item in the Group request to the coral service. This isn't recorded during PrepareResource or CacheEmbeddings calls because what we care about is how frequent the cache is hit when the user-facing feature is triggered (which issues a Group request). This is recorded when embedding engine is processing each entity in a Group request and checks whether it is present in the embedding cache database. hcyang@google.com cros-odml-foundations-eng@google.com The return value of a Group request to the coral service for individual engines of the service. The coral service is a pipeline of 3 engines: Embedding, Clustering, and TitleGeneration. If any engine returns an error when processing the request, the service returns the corresponding error as response. It is recorded when the {EngineType} finishes processing a request (success or failure). hcyang@google.com cros-odml-foundations-eng@google.com The return value of a {OperationType} request to the coral service, hosted by the odml daemon. It is recorded when any request to coral service completes (success or failure). hcyang@google.com cros-odml-foundations-eng@google.com The number of input items in the Group request. This is recorded everytime the backend receives a Group request. hcyang@google.com cros-odml-foundations-eng@google.com Milliseconds taken by the generate embedding step of the embedding engine in coral service. This only counts the latency of the inference itself; model loading latency isn't counted. This is recorded when a generate embedding operation completes with a successful return status. hcyang@google.com cros-odml-foundations-eng@google.com Milliseconds taken by the load model step of the embedding engine in coral service. The embedding model needs to be loaded for the embedding engine to process requests, so a load model operation will be instantiated if the engine receives a request while the model hasn't been loaded. This is recorded when a load model operation completes with a successful return status. hcyang@google.com cros-odml-foundations-eng@google.com Milliseconds taken by the generate title step of the title generation engine in coral service. This only counts the latency of the inference itself; model loading latency isn't counted. This is recorded when a generate title operation completes with a successful return status. hcyang@google.com cros-odml-foundations-eng@google.com Milliseconds taken by the load model step of the title generation engine in coral service. The title generation model needs to be loaded for the engine to process requests, so a load model operation will be instantiated if the engine receives a request while the model hasn't been loaded. This is recorded when a load model operation completes with a successful return status. hcyang@google.com cros-odml-foundations-eng@google.com Milliseconds taken by a Group request to the coral service for individual engines of the service. The coral service is a pipeline of 3 engines: Embedding, Clustering, and TitleGeneration, and the latency of the service is roughly the summation of all 3 engines. This is a breakdown of latency taken by individual engines. It is recorded when the {EngineType} finishes processing a Group request with successful return status. hcyang@google.com cros-odml-foundations-eng@google.com Milliseconds taken by a {OperationType} request to the coral service, hosted by the odml daemon. It is recorded when any request to coral service completes with successful return status. hcyang@google.com cros-odml-foundations-eng@google.com The minimum difference ratio of each group returned from the clustering engine, compared with all groups in the title cache. When this ratio is lower than a threshold, the cache will be hit and the title will be reused, and this metrics can help us understand what is the most suitable value of that ratio. This is recorded when title generation engine is processing each entity in a Group request and checks whether it is similar enough to any groups in the title cache (reported regardless of cache hit or not). hcyang@google.com cros-odml-foundations-eng@google.com Whether the title cache is hit for each item in the Group request to the coral service. This is recorded when title generation engine is processing each entity in a Group request and checks whether it is present in the title cache. hcyang@google.com cros-odml-foundations-eng@google.com The success or failure result of each title generation. This is recorded exactly once when title generation engine is processing each group returned from the clustering engine. hcyang@google.com cros-odml-foundations-eng@google.com The length of each model inference prompt formed by the title generation engine, in tokens (the unit of text representation in our on device models). This is reported for each group returned from the clustering engine, that is processed in the model inference step. hcyang@google.com cros-odml-foundations-eng@google.com The length of each generated title from title generation engine, in characters (bytes). This is reported whenever title generation engine generates a new title for a group successfully (empty title is treated as failure and won't be reported). hcyang@google.com cros-odml-foundations-eng@google.com The length of each generated title from title generation engine, in English words. This is defined by "number of white spaces + 1" in the title, which is a good enough estimation for English words. This is not useful for many other languages, and should be reported with some extra logic after we support languages other than English. Currently, this is reported whenever title generation engine generates a new title for a group successfully (empty title is treated as failure and won't be reported). hcyang@google.com cros-odml-foundations-eng@google.com Whether the title generation model is already loaded when coral service receives a Group request. This is recorded when title generation engine is processing a Group request and reaches the step that it needs to check whether the model is already loded. iby@chromium.org chromeos-data-eng@google.com (ChromeOS only) An enum indicating the reasons why adding a weight to crash reports succeeded or failed. This is recorded after each crash with client-side weighting -- most commonly, those detected by anomaly_detector. Specifically, these metrics are recorded in CrashCollector::AddCrashMetaWeight() and CrashCollector::AddCrashMetaUploadData(). iby@chromium.org chromeos-data-eng@google.com (Chrome OS only) An enum indicating the reasons for removal of crash reports on devices. Generally, we'll remove crash reports after successfully sending them, but there are other reasons for removal (e.g. if the metadata file was malformed). These should be rare, but bugs in the crash reporting system may cause us to start removing crashes before sending them more often. This metric is intended to monitor crash reporting system health. iby@chromium.org vapier@chromium.org Generic event of interest from Chrome OS. Intended mainly to help assess the frequency of rare error conditions. semenzato@chromium.org bsimonnet@chromium.org Total CPU time accumulated since the last version update. Reported at most once a day. semenzato@chromium.org bsimonnet@chromium.org iby@chromium.org chromeos-data-eng@google.com Total use time (device ON and not asleep) in the previous day, or the most recent day the device was in use. Reported at most once a day. yich@google.com cros-hwsec-userland-eng+uma@google.com Each sample is the result of the install_attributes restoration process. This is logged when lockbox-cache tries to restore the missing install_attributes. See cryptohome::RestoreResult in src/platform2/cryptohome/lockbox-cache.cc for more context. sadmansakib@google.com cros-hwsec-userland-eng+uma@google.com Each sample is the result of the install_attributes initialization status. This is logged when DeviceManagement::Initialize() completes initialization of install_attributes. See InstallAttributes::Status in src/platform2/device_management/install_attributes/install_attributes.h for context. achuith@chromium.org tls@chromium.org Number of users home directories on the device. Logged once a day. achuith@chromium.org omrilio@chromium.org Number of user home dirs on device. Logged once a day, if disk usage is high. sarthakkukreti@google.com chromeos-storage@google.com Chrome OS KB in use in the /home/chronos filesystem tree. Logged once a day during log file cleanup. Warning: this histogram was expired from 2022-04-10 to 2023-06-01; data may be missing. sarthakkukreti@google.com chromeos-storage@google.com Chrome OS KB in use in the /var filesystem tree. Logged once a day during log file cleanup. Warning: this histogram was expired from 2022-05-01 to 2023-06-01; data may be missing. kimjae@chromium.org chromeos-core-services@google.com The result of an attempt to Install a DLC package. DLCs are ChromiumOS Software packages that are installed in the stateful partition. kimjae@chromium.org chromeos-core-services@google.com The storage space used by DLC packages on the device. This metric is reported daily by the dlcservice. DLCs are ChromiumOS software packages that are installed in the stateful partition. kimjae@chromium.org chromeos-core-services@google.com The result of an attempt to Uninstall a DLC package. DLCs are ChromiumOS Software packages that are installed in the stateful partition. Warning: this histogram was expired from Feb 2025 to March 2026; data may be missing. gwendal@google.com chromeos-storage@google.com eMMC [5.0] Device lifetime estimation for flash. This field provides an estimated indication about the device lifetime that is reflected by the averaged wear out of memory of {Type} relative to its maximum estimated lifetime. iby@google.com chromeos-data-eng@google.com On ChromeOS, number of external metrics samples read in from the platform. Emitted once every 30 seconds. If this is too large (over 100,000), we will silently lose metrics. Additionally, 100,000 is the largest number we'll ever record here: we stop counting when we hit 100,000. jintaolin@chromium.org yichenyu@chromium.org cros-network-metrics@google.com Type of the firmware dump that is submitted for pseudonymization. Emitted every time a new pseudonymization is requested. Design doc: go/cros-fbpreprocessord-dd jintaolin@chromium.org yichenyu@chromium.org cros-network-metrics@google.com Reports whether the collection of {FirmwareType} firmware dumps is allowed or not. Emitted every time the bit is updated (user logs in/out, Finch updated, etc). Design doc: go/cros-fbpreprocessord-dd jintaolin@chromium.org yichenyu@chromium.org cros-network-metrics@google.com Number of firmware dumps of type {FirmwareType} that are available for collection. Emitted periodically, every 5 minutes. Design doc: go/cros-fbpreprocessord-dd jintaolin@chromium.org yichenyu@chromium.org cros-network-metrics@google.com Result of the pseudonymization operations of firmware dumps of type {FirmwareType}. Emitted every time a new firmware dump completes pseudonymization, succesfully or not. Design doc: go/cros-fbpreprocessord-dd shraash@google.com chromeos-data-eng@google.com Records number of boot attempts on a device since receiving a variations safe seed from Chrome. This value is reported every time a device boots. keiichiw@google.com uekawa@google.com The total number of allocated file descriptors. This value is obtained from /proc/sys/fs/file-nr and reported once per day. gwendal@google.com chromeos-storage@google.com Reports fsck result on {Partition}. Reported once per filesystem mount. gwendal@google.com chromeos-storage@google.com Number of error in file system {Partition}, as reported by dumpe2fs "FS Error count" field. Reported once per boot. gwendal@google.com chromeos-storage@google.com {MountResult} is true when kernel reports that file system {Partition} is/was needed. kimjae@chromium.org chromeos-core-services@google.com Records if the system firmware mismatched OS bundled firmware. Reported once per boot by dev_debug_vboot. Warning: this histogram was expired from 2024-09-02 to 2025-03-27; data may be missing. justinoue@google.com chromeos-flex-eng@google.com ChromeOS Flex runs on a various configurations of x86 firmware. This metric collects the method used to boot the device. This metric is only recorded on ChromeOS Flex devices. It is recorded once per boot. nicholasbishop@google.com chromeos-flex-eng@google.com ChromeOS Flex runs on a wide range of x86-64 CPUs. This metric categorizes the CPU by its ISA level. This metric is only recorded on ChromeOS Flex devices. It is recorded once per boot. tinghaolin@google.com chromeos-flex-eng@google.com Result of checking if the device has permission to send hardware data and whether it is due to enabled policies or end-user opt-in. When a user logs in to a ChromeOS Flex device, hardware data transmission and related checks will be initiated. ChromeOS Flex Hardware Information Service (flex_hwis) checks if the device is authorized to send hardware data to the server. If the device is managed, management policies will be checked. If the device is unmanaged, the service will check if consent has been granted via the OOBE or settings screen before sending any data. Once the hardware data has been successfully transmitted to the server, no further transmission or related checks will be performed for the next 24 hours. tinghaolin@google.com chromeos-flex-eng@google.com Result of checking if the flex_hwis utility successfully calls DELETE API to delete data. When a user logs in to a ChromeOS Flex device, hardware data transmission and related checks will be initiated. In ChromeOS Flex Hardware Information Service (flex_hwis), if the user doesn't consent to send data, the client service will send a request to the server to delete the hardware data stored on the server. tinghaolin@google.com chromeos-flex-eng@google.com Result of checking if the flex_hwis utility successfully calls POST API to create data. When a user logs in to a ChromeOS Flex device, hardware data transmission and related checks will be initiated. In ChromeOS Flex Hardware Information Service (flex_hwis), each device has a unique identifier. If the unique identifier was just generated by the service client side, the service will then call the POST API to create the data slot on the server side and record whether the API request was successful. Once the hardware data has been successfully transmitted to the server, no further transmission or related checks will be performed for the next 24 hours. tinghaolin@google.com chromeos-flex-eng@google.com Result of checking if the flex_hwis utility successfully calls PUT API to update data. When a user logs in to a ChromeOS Flex device, hardware data transmission and related checks will be initiated. In ChromeOS Flex Hardware Information Service (flex_hwis), each device has a unique identifier. If the unique identifier already exists on the service client side, the service will then call the PUT API to update the data slot on the server side and record whether the API request was successful. Once the hardware data has been successfully transmitted to the server, no further transmission or related checks will be performed for the next 24 hours. tbrandston@google.com chromeos-flex-eng@google.com Sent once when a ChromeOS Flex device sees what method was used for install. When a ChromeOS Flex device is installed via Flexor (we expect to add more methods in the future), a file is created on the stateful partition. If the file exists at boot, we delete it and emit this metric. (If we fail to delete the file, we don't emit the metric.) andrebraga@google.com chromeos-flex-eng@google.com Due to using legacy page flips and having little-to-no overlap promotion support, Flex tends to reach the 3 page flip flake threshold. This is a metric for finding a better threshold for Flex devices. This metric is only recorded on ChromeOS Flex devices. It is recorded once per page flip flake. There will be overcounting: a device that flakes 3 times in a row will also emit a metric for "1 flake" and "2 flakes," but we are more concerned with finding the upper limit of flakes rather than specific counts. This histogram replaced `Platform.FlexPageFlipFlakes` as the metric was only emitted if we reached the threshold and never before. nicholasbishop@google.com chromeos-flex-eng@google.com A sparse histogram of the size (in MiB) of the partition labeled "{Partition}". This is the size as defined by the partition table, not the size of the filesystem (if any). Unlike most ChromeOS boards, ChromeOS Flex occasionally migrates the disk layout of existing installations during the update process, so not all installations have the same layout. This metric is only recorded on ChromeOS Flex devices. It is recorded once per boot. andrebraga@google.com chromeos-flex-eng@google.com The result of each `uefi_plugin` update on Flex devices. This metric is only recorded on ChromeOS Flex devices. Once per boot, any `uefi_plugin` updates in the fwupd history are recorded. rishbhagr@google.com chromeos-fwupd@google.com Indicates the return value of a firmware activation operation via fwupd. Reported once per activation operation. rishabhagr@google.com chromeos-fwupd@google.com Time elapsed during the firmware update operation. Sent after every sucessful update firmware operation via fwupd. rishabhagr@google.com chromeos-fwupd@google.com Indicates the return value of a firmware update operation via fwupd. Reported once per update operation. fbarchard@chromium.org pwnall@chromium.org The maximum supported micro-architecture on an Intel platform. This value is logged at program start time. grundler@chromium.org groeck@chromium.org bgeffon@chromium.org chromeos-data-eng@google.com Count of kernel crashes during the previous day, or the most recent day the device was in use. Reported at most once a day. grundler@chromium.org groeck@chromium.org bgeffon@chromium.org chromeos-data-eng@google.com Count of kernel crashes since the last OS update, normalized as number of crashes per year of active use (active use = device is ON and not asleep). Reported daily. grundler@chromium.org groeck@chromium.org bgeffon@chromium.org chromeos-data-eng@google.com Count of kernel crashes since the last OS update, normalized as number crashes per year of CPU time. Reported daily. grundler@chromium.org groeck@chromium.org bgeffon@chromium.org chromeos-data-eng@google.com Count of kernel crashes since the last OS update, reported daily. grundler@chromium.org groeck@chromium.org bgeffon@chromium.org chromeos-data-eng@google.com Count of kernel crashes during the previous epoch-week, or the most recent epoch-week the device was in use. Reported at most once a week. Epoch-weeks divide the time in 7-day intervals starting at the UNIX epoch. grundler@chromium.org groeck@chromium.org bgeffon@chromium.org chromeos-data-eng@google.com Time elapsed between the last two kernel crashes. Sent after every kernel crash. saboyapati@google.com chromeos-data-eng@google.com The number of "kernel panic" events recorded in the BIOS event log per day. This metric is updated by the metrics_daemon, which accumulates events in persistent storage and reports the total exactly once per 24-hour period. Once a report is sent to UMA, the local counter is reset to zero to prevent duplicate reporting. This provides an independent validation of fatal kernel crashes by using firmware persistent memory saboyapati@google.com chromeos-data-eng@google.com The number of "watchdog reset" events recorded in the BIOS event log per day. This metric is updated by the metrics_daemon, which accumulates events in persistent storage and reports the total exactly once per 24-hour period. Once a report is sent to UMA, the local counter is reset to zero to prevent duplicate reporting. This provides an independent validation of fatal kernel crashes by using firmware persistent memory chensa@google.com cros-hwsec-userland-eng+uma@google.com Each sample is the result code of a libhwsec PinWeaverManagerImpl::ReplayLogEntries operation. Categorized into 2 replay types(Normal/Full), depending on whether all of the log entries were used for replay, as this will result in different error distributions. This is logged after the ReplayLog operation is attempted, during libhwsec's retry handling when the PinWeaver client loses sync with the server (GSC). chensa@google.com cros-hwsec-userland-eng+uma@google.com Each sample is the result code of a libhwsec PinWeaverManager::SyncHashTree operation. This is logged after the Sync operation is attempted, during libhwsec's retry handling when the PinWeaver client loses sync with the server (GSC). chensa@google.com cros-hwsec-userland-eng+uma@google.com Each sample is the result of the libhwsec PinWeaver {ReplayOperationType} operation. This is logged when a {ReplayOperationType} replay operation is attempted during libhwsec's retry handling, when the PinWeaver client loses sync with the server (GSC). The metric is categorized by the ReplayEntry types, where {ReplayEntryType} differentiates the status of the replay before attempting to replay the current log entry. yich@google.com cros-hwsec-userland-eng+uma@google.com Each sample is the result code of a libhwsec operation issued through libhwsec that belongs to {Category}. Success is 0. For the other error codes, see src/platform2/libhwsec/error/tpm_retry_action.h. Recorded when the libhwsec operation finished in the middleware. njrafi@google.com cros-odml-foundations-eng@google.com The types of image generated by Mantis. This is recorded when the model succesfully generated an image. Even if the image failed Trust and safety check, it is still considered in the count. fairuzi@google.com cros-odml-foundations-eng@google.com Milliseconds taken by a {OperationType} request to the Mantis service. It is recorded when any request to Mantis service completes with successful return status. fairuzi@google.com cros-odml-foundations-eng@google.com Whether the model is already loaded (i.e. processor is already initialized). This is recorded when mantis service is receiving a processor initialization request and reaches the step that it needs to check whether the processor is already initialized. hajimehoshi@chromium.org kouhei@chromium.org sonnyrao@chromium.org chromeos-memory@google.com Various memory usage amount on Chrome OS devices (snapshotted every 30s). {PlatformMeminfoSize} bgeffon@chromium.org khmel@chromium.org chromeos-memory@google.com Memory usage of all ARC and ARCVM processes in Chrome OS, reported every 10 minutes. {ProcessMemoryType} bgeffon@chromium.org chromeos-memory@google.com Memory usage of browser and helper processes (excluding GPU process and renderers) in Chrome OS, reported every 10 minutes. {ProcessMemoryType} bgeffon@chromium.org chromeos-memory@google.com Memory usage of user-level daemons in Chrome OS, reported every 10 minutes. {ProcessMemoryType} bgeffon@chromium.org chromeos-memory@google.com Memory usage of the GPU process in Chrome OS, reported every 10 minutes. {ProcessMemoryType} kawasin@google.com chromeos-memory@google.com The error types from psi memory policy feature. This is recorded each time the psi memory handler detects an error. PsiPolicy is not expected to fail. Even if it fails continuously, it reports the error at most once per 1 second. If any error is detected, psi policy feature should be turned off by the finch flag. kawasin@google.com chromeos-memory@google.com The reason of reclaiming memory on memory pressure. This is recorded when resourced detects memory pressure and decides to reclaim memory by discarding tabs or killing processes in VMs. This is reported at most once per 1 second. bgeffon@chromium.org chromeos-memory@google.com Memory usage of renderer processes in Chrome OS, reported every 10 minutes. {ProcessMemoryType} bgeffon@chromium.org chromeos-memory@google.com Memory usage of VMs (crostini and others, except for ARCVM) in Chrome OS, reported every 10 minutes. {ProcessMemoryType} hajimehoshi@chromium.org kouhei@chromium.org sonnyrao@chromium.org chromeos-memory@google.com Various memory usage % of total memory on Chrome OS devices (snapshotted every 30s). Warning: this histogram was expired from 2021-07-02 to 2022-01; data may be missing. {PlatformMeminfoPercentage} hikalium@chromium.org chromeos-kernel-stability@google.com The microcode version for the CPU 0 at program start time. If this information is not available on the system (including on errors), the value logged will be -1 (0xffffffff). roccochen@chromium.org chromeos-minidiag-eng@google.com Total number of launches of the MiniDiag (pre-boot diagnostic tool) since the last upload. This metrics is recorded right after booting into ChromeOS. This metrics leverages a coreboot command, elogtool, to retrieve the event log and count launch events. roccochen@chromium.org chromeos-minidiag-eng@google.com Records the duration that the MiniDiag (pre-boot diagnostic tool) is open. This metrics is recorded right after booting into ChromeOS. This metrics leverages a coreboot command, elogtool, to retrieve the event log and count launch events. roccochen@chromium.org chromeos-minidiag-eng@google.com Test item-specific duration of the MiniDiag (pre-boot diagnostic tool) since the last upload. This metrics is recorded right after booting into ChromeOS. This metrics leverages a coreboot command, elogtool, to retrieve the event log and count launch events. The TestType is the same as cros_diagnostics_diag_types listed in coreboot/util/cbfstool/eventlog.c since all the data are parsed from them. roccochen@chromium.org chromeos-minidiag-eng@google.com Test item-specific results of the MiniDiag (pre-boot diagnostic tool) since the last upload. This metrics is recorded right after booting into ChromeOS. This metrics leverages a coreboot command, elogtool, to retrieve the event log and count launch events. The TestType and MiniDiagResultType are the same as cros_diagnostics_diag_types and cros_diagnostics_diag_results listed in coreboot/util/cbfstool/eventlog.c since all the data are parsed from them. nancylanxiao@google.com xanth@google.com domfc@google.com cbe-cep-eng@google.com Recorded when missive clientlib calls ReportQueue::Enqueue to post an event to ERP. It counts occurrences of the call returning success or each possible error Status. nancylanxiao@google.com xanth@google.com domfc@google.com cbe-cep-eng@google.com Recorded when missive blocks a record being processed and sent to the server. Recorded by the Missive daemon at the moment the record is received by `Storage::Write`. It counts occurrences of number of times it has been called per Destination. nancylanxiao@google.com xanth@google.com domfc@google.com cbe-cep-eng@google.com The percentage of CPU time that the Missive daemon has been using. The CPU usage is not expected to be high and any usage beyond 100% is considered to be in the overflow bucket. This is reported once every 10 minutes and only if the Missive daemon is running. nancylanxiao@google.com xanth@google.com domfc@google.com cbe-cep-eng@google.com Recorded once each time reporting::error::DATA_LOSS is returned in src/platform2/missive/. There is a 1:1 relationship between the UMA values and error messages used with reporting::error::DATA_LOSS so that we can understand exactly which parts of the code are failing. nancylanxiao@google.com xanth@google.com domfc@google.com cbe-cep-eng@google.com Recorded when the Missive daemon attempts to delete empty multigeneration queue directories on startup or when the periodic timer triggers. A value of True indicates that no errors occurred while attempting to delete directories and that zero or more directories were deleted. False indicates that at least one directory that should have been deleted was not deleted due to an error. nancylanxiao@google.com xanth@google.com domfc@google.com cbe-cep-eng@google.com Recorded when missive recieves a response to its request for an encryption key from the server. Counts the success/failures of key requests. nancylanxiao@google.com xanth@google.com domfc@google.com cbe-cep-eng@google.com The amount of memory that the Missive daemon has been using. This is reported once every 10 minutes and only if the Missive daemon is running. nancylanxiao@google.com xanth@google.com domfc@google.com cbe-cep-eng@google.com Recorded when Missive runs the storage directory migration function (called each time when Missive starts). It counts the status of the migration. nancylanxiao@google.com xanth@google.com domfc@google.com cbe-cep-eng@google.com Recorded once each time reporting::error::PERMISSION_DENIED is returned in src/platform2/missive/. There is a 1:1 relationship between the UMA values and error messages used with reporting::error::PERMISSION_DENIED so that we can understand exactly which parts of the code are failing. nancylanxiao@google.com xanth@google.com domfc@google.com cbe-cep-eng@google.com Counter of each case RESOURCE_EXHAUSTED error was returned by missive Storage to the caller. This is reported only when such error happens (rarely), and only if the Missive daemon is running. nancylanxiao@google.com xanth@google.com domfc@google.com cbe-cep-eng@google.com Recorded status of every instance missive starts (usually once per device boot). nancylanxiao@google.com xanth@google.com domfc@google.com cbe-cep-eng@google.com Total amount of space freed by controlled degradation performed by Storage. nancylanxiao@google.com xanth@google.com domfc@google.com cbe-cep-eng@google.com The amount of disk storage that the Missive daemon has been using for storing encrypted records. This is reported once every hour and only if the Missive daemon is running. nancylanxiao@google.com xanth@google.com domfc@google.com cbe-cep-eng@google.com The amount of disk storage that the Missive daemon has been using for storing encrypted records on devices that have not uploaded any data for the last 24 hours (could have updated the encryption key). This is reported once every hour and only if the Missive daemon is running. nancylanxiao@google.com xanth@google.com domfc@google.com cbe-cep-eng@google.com Recorded once each time reporting::error::UNAVAILABLE is returned in src/platform2/missive/. There is a 1:1 relationship between the UMA values and error messages used with reporting::error::UNAVAILABLE so that we can understand exactly which parts of the code are failing. nancylanxiao@google.com xanth@google.com domfc@google.com cbe-cep-eng@google.com Would only be true. Recorded whenever an unusual timestamp is encountered when enqueuing a record, which will be rejected. andrewlassalle@google.com cros-device-enablement@google.com Result of the |CheckForWedgedModem| function. The function checks the modem state after modemfwd starts, and tries to recover the modem if the modem is non responsive. This function is only called once after boot, so a single value is emitted per boot. Warning: this histogram was expired from 2025-07-06 to 2027-04-05; data may be missing. andrewlassalle@google.com ujjwalpande@google.com Result of the DLC install action performed by modemfwd. Some device variants use a DLC to store their FW. When this DLC is installed, a metric is logged. andrewlassalle@google.com ujjwalpande@google.com Result of each DLC uninstall action performed by modemfwd. Modemfwd will remove any modem DLCs that are not for the device's variant. Each uninstall will log a metric. andrewlassalle@google.com cros-device-enablement@google.com The result of each modem FW install attempt. ujjwalpande@google.com cros-device-enablement@google.com Metric to track time taken by modemfwd helpers in seconds to flash the firmwares to modem. Values will be reported only for successful flashing cases as flashing times in case of failures could be misleading. Warning: this histogram was expired from 2023-06-17 to 2024-09-17, data may be missing. andrewlassalle@google.com cros-device-enablement@google.com The location that modemfwd uses for the FW install. After modemfwd determines if a DLC will be used or not, a metric is logged with the location used. ujjwalpande@google.com cros-device-enablement@google.com Report state of modem recovery operation. apronin@chromium.org cros-hwsec+uma@google.com File system encryption key status for the encrypted stateful file system on Chrome OS. The encryption key is the one that is used by the kernel to protect actual file contents on disk. apronin@chromium.org cros-hwsec+uma@google.com Type/Origin of the system key used for the encrypted stateful file system on Chrome OS. This key is used to wrap the actual file system encryption key. hcyang@google.com cros-odml-foundations-eng@google.com Fraction of total CPU resources used by ChromeOS ODML Service, sampled every 5 minutes. hcyang@google.com cros-odml-foundations-eng@google.com Peak total malloc memory used by ChromeOS ODML Service over the last one hour. Sampled every 5 minutes, so may miss short-lived spikes. hcyang@google.com cros-odml-foundations-eng@google.com Peak total resident set size memory used by ChromeOS ODML Service over the last one hour. Sampled every 5 minutes, so may miss short-lived spikes. hcyang@google.com cros-odml-foundations-eng@google.com Peak total swap memory used by ChromeOS ODML Service over the last one hour. Sampled every 5 minutes, so may miss short-lived spikes. hcyang@google.com cros-odml-foundations-eng@google.com Total malloc memory used by ChromeOS ODML Service, sampled every 5 minutes. hcyang@google.com cros-odml-foundations-eng@google.com Total resident set size memory used by ChromeOS ODML Service, sampled every 5 minutes. hcyang@google.com cros-odml-foundations-eng@google.com Total swap memory used by ChromeOS ODML Service, sampled every 5 minutes. gwendal@google.com chromeos-storage@google.com Number of disk sectors per second read by Chrome OS in a long interval (currently 30s) gwendal@google.com chromeos-storage@google.com Number of disk sectors per second read by Chrome OS in a short interval (currently 1s, sampled every 30s) vovoy@chromium.org chromeos-memory@google.com Memory notification count in 10 minutes, reported every 10 minutes. vovoy@chromium.org chromeos-memory@google.com Milliseconds taken by a request to VM Memory Management Service to reclaim memory from VMs. This is recorded by resourced every time it makes a reclaim request to the VM Memory Management Service to try to resolve memory pressure in the host. hcyang@google.com cros-hwsec+uma@google.com The result of fetching the recoverable key store certificate files from a gstatic URL. This recorded after each fetch attempt, which is scheduled periodically (once per day, retries every 10 minutes if fails). chensa@google.com cros-odml-foundations-eng@google.com Round-trip latency (milliseconds) for safety filtering using ruleset {Ruleset}. Measures the time from request initiation to final safety verdict from Hades. Includes platform-chrome-arcvm mojo communication, ArcSafetyService (mojo-proxy) to Hades, and Hades inference. This is recorded when SafetyServiceManager gets classify safety request, but only for successful round trips with explicit pass/blocked verdicts. chensa@google.com cros-odml-foundations-eng@google.com The safety verdict for ruleset {Ruleset}. This is recorded when SafetyServiceManager gets classify safety request. chensa@google.com cros-odml-foundations-eng@google.com Whether is succeed or failed to get an cloud session from CrosSafetyService (in chrome). Captured during SafetyServiceManager initialization, prior to safety classification requests. chensa@google.com cros-odml-foundations-eng@google.com Whether is succeed or failed to get an on-device session from CrosSafetyService (in chrome). Captured during SafetyServiceManager initialization, prior to safety classification requests. asavery@chromium.org gwendal@chromium.org chromeos-storage@google.com The remaining reserved space (SMART 232). The value counts down typically from 100 to 0, sent at boot. asavery@chromium.org gwendal@chromium.org chromeos-storage@google.com The total number of 512-byte sectors written during the lifetime of the device, sent at boot. asavery@chromium.org gwendal@chromium.org chromeos-storage@google.com The total number of 512-byte sectors written during the lifetime of the device, sent at boot. asavery@chromium.org gwendal@chromium.org chromeos-storage@google.com Percentage Used Endurance Indicator. A value of 0 indicates a new device, a value of 100 indicates the device is at the end of its lifespan as projected by the manufacturer. Values greater than 100 indicate the device is beyond the projected lifespan. Maximum value is 255, sent at boot. gwendal@chromium.org iby@chromium.org chromeos-data-eng@google.com Records the feature level of the device. Recorded in every UMA upload. See libsegmentation in platform2 for context. gwendal@chromium.org iby@chromium.org chromeos-data-eng@google.com Records the scope level of the device (Soft vs Hard Branded). Recorded in every UMA upload. See libsegmentation in platform2 for context. gwendal@google.com chromeos-storage@google.com Disk communication errors (SMART 199), sent at boot. gwendal@google.com chromeos-storage@google.com Uncorrectable disk errors (SMART 187), sent at boot. sarthakkukreti@chromium.org gwendal@chromium.org chromeos-storage@google.com Chrome OS stateful partition format. Sampled once per boot. asavery@chromium.org gwendal@chromium.org chromeos-storage@google.com Chrome OS stateful partition space free. Sampled once daily. asavery@chromium.org gwendal@chromium.org chromeos-storage@google.com Chrome OS stateful partition lifetime writes. Sampled once daily. asavery@chromium.org gwendal@chromium.org chromeos-storage@google.com The amount of time in hours since the last trim when chromeos-trim triggers a trim for the stateful partition. The chromeos-trim script is run daily, but a trim is only triggered if the previous run was interrupted, the amount of writes since the last trim is greater than X% of the remaining space in stateful or we have not trimmed in 7 days. Reported at most once a day. Warning: this histogram was expired from 2022-10-21 to 2023-08-10; data may be missing. asavery@chromium.org gwendal@chromium.org chromeos-storage@google.com The amount of data in the stateful partition that is erased when chromeos-trim triggers a trim. The chromeos-trim script is run daily, but a trim is only triggered if the previous run was interrupted, the amount of writes since the last trim is greater than X% of the remaining space in stateful or we have not trimmed in 7 days. Reported at most once a day. Warning: this histogram was expired from 2022-10-21 to 2023-08-10; data may be missing. sarthakkukreti@google.com chromeos-storage@google.com Chrome OS stateful partition usage level. Warning: this histogram was expired from 2024-03-17 to 2024-08-01; data may be missing. asavery@chromium.org gwendal@chromium.org chromeos-storage@google.com Chrome OS stateful partition space used. Sampled once daily. asavery@chromium.org gwendal@chromium.org chromeos-storage@google.com Chrome OS stateful partition KiB writes per day. Sampled once daily. korneld@chromium.org chromeos-devices-team@google.com MMC error counters for the MMC that controls the rootfs drive. Only reported on machines that use an MMC controller for rootfs. The counters represent the number of errors per wall-clock hour. asavery@chromium.org gwendal@chromium.org chromeos-storage@google.com Vendor specific estimate of the percentage of NVM subsystem life used based on the actual usage and the manufacturer's prediction of NVM life. A value of 100 indicates the estimated endurance has been consumed, but may not indicate a failure. Values can exceed 100, with percentages greater than 254 represented as 255. asavery@chromium.org gwendal@chromium.org chromeos-storage@google.com UFS Device life time estimation. This field provides an indication of the device life time based on the amount of performed program/erase cycles for memory {Type}. The calculation is vendor specific. sarthakkukreti@google.com chromeos-storage@google.com Sparse histogram of internal storage device capabilities. Sampled once per boot. asavery@chromium.org chromeos-memory@google.com chromeos-storage@google.com Number of pages swapped IN over a day, sampled daily. asavery@chromium.org chromeos-memory@google.com chromeos-storage@google.com Number of pages swapped OUT over a day, sampled daily. Warning: this histogram was expired from 2024-03-17 to 2024-08-01; data may be missing. sarthakkukreti@google.com chromeos-storage@google.com Time taken to persist LVM metadata. Recorded once per migration attempt. sarthakkukreti@google.com chromeos-storage@google.com Time taken to resize the filesystem. Recorded once per migration attempt. sarthakkukreti@google.com chromeos-storage@google.com Result of stateful migration to thinpool. Recorded once per migration attempt. sarthakkukreti@google.com chromeos-storage@google.com Time taken to revert the migration. Recorded once per failed migration attempt. sarthakkukreti@google.com chromeos-storage@google.com Time taken to persist thinpool metadata. Recorded once per migration attempt. sarthakkukreti@google.com chromeos-storage@google.com Time taken for a migration attempt. Recorded once per migration attempt. sarthakkukreti@google.com chromeos-storage@google.com Number of migration attempts left at completion. Captures whether multiple attempts were required to complete migration. Recorded once after successful migration. jettrink@google.com cros-hwsec+uma@google.com The count of potential GSC resets for AP RO Verification due to system event. granaghan@google.com cros-hwsec+uma@google.com Time in milliseconds AP RO verification took. Captured every cold boot. yich@google.com cros-hwsec-userland-eng+uma@google.com Each sample is the result code of a TPM authorized command issued through tcsd. Success is 0. For the other error codes, see /usr/include/tss/tpm_error.h. yich@google.com cros-hwsec-userland-eng+uma@google.com Reporting the TPM command ordinal that results in TPM_E_AUTH2FAIL code. Note that this is only applicable for TPM1.2. Warning: this histogram was expired from Oct 8, 2022 to June 26, 2023; data may be missing. yich@google.com cros-hwsec-userland-eng+uma@google.com Reporting the TPM command ordinal that results in TPM_E_AUTHFAIL code. Note that this is only applicable for TPM1.2. Warning: this histogram was expired from Oct 8, 2022 to June 26, 2023; data may be missing. granaghan@google.com cros-hwsec+uma@chromium.org Number of times the crypto engine returned busy. Captured every cold boot. granaghan@google.com cros-hwsec+uma@chromium.org Time in ms the crypto engine took to initialize. Captured every cold boot. yich@google.com cros-hwsec-userland-eng+uma@google.com Each sample is the value of the TPM dictionary attack counter reported at boot and hourly while running. Any non-zero value is unexpected. yich@google.com cros-hwsec-userland-eng+uma@google.com Each sample is the status of an hourly attempt to reset the TPM dictionary attack counter. granaghan@google.com cros-hwsec+uma@chromium.org Number of times the dispatcher returned busy. Captured every cold boot. yich@google.com cros-hwsec-userland-eng+uma@google.com Each sample is the result code of a TPM command issued through tcsd. Success is 0. For the other error codes, see /usr/include/tss/tpm_error.h. granaghan@google.com cros-hwsec+uma@google.com AP RO Verification status and detailed result. Captured every cold boot. granaghan@google.com cros-hwsec+uma@chromium.org Number of times the filesystem returned busy. Captured every cold boot. granaghan@google.com cros-hwsec+uma@google.com Time in milliseconds filesystem initialization and scanning took. Captured every cold boot. granaghan@google.com cros-hwsec+uma@google.com Number of bytes used by the filesystem. Captured every cold boot. anatol@google.com cros-hwsec+uma@google.com Trusted Platform Module hardware alerts that signal about the chip abnormal situation. chenyian@google.com cros-hwsec-userland-eng+uma@google.com Report if TPM clear is success or not after a power wash. TPM should not be owned after the power wash. yich@google.com cros-hwsec-userland-eng+uma@google.com Report the TPM ownership can be take or not for each TPM initialization process. The process usually happen at the first boot of device. granaghan@google.com cros-hwsec+uma@chromium.org Number of times a process on the TPM exceeded its timeslice. Captured every cold boot. yich@google.com cros-hwsec+uma@google.com The amount of time for Chrome OS to take TPM ownership. Recorded when tpm_manager takes the ownership of TPM. yich@google.com cros-hwsec+uma@google.com The status of the secrets that tpm manager holds. Warning: this histogram was expired from 2021-09-01 to 2022-06-14; data may be missing. apronin@chromium.org cros-hwsec+uma@google.com Indicates a fingerprint of hardware + firmware versions for the TPM chip present in a Chrome OS device. chingkang@chromium.org cros-hwsec+uma@google.com The TPM1 command and response code send from {Client} to trousers. The value is the encoding of 2 bytes command code and 2 bytes response code. chingkang@chromium.org cros-hwsec+uma@google.com The TPM2 command and response code send from {Client} to trunks. The value is the encoding of 2 bytes command code and 2 bytes response code. yich@google.com cros-hwsec+uma@google.com The time we spend on the TPM that is not directly related to the user authenticate event. Recorded when user tries to authenticate the device. yich@google.com cros-hwsec+uma@google.com The time we spend on the TPM that is directly related to the user authenticate event. Recorded when user tries to authenticate the device. yich@google.com cros-hwsec+uma@google.com The total time for the user authenticate event. Recorded when user tries to authenticate the device. chingkang@chromium.org cros-hwsec+uma@google.com Command code of the first timeout writing TPM command chingkang@chromium.org cros-hwsec+uma@google.com System uptime when first timeout writing TPM command occurs chingkang@chromium.org cros-hwsec+uma@google.com The write errno recovered after rebinding the TPM driver; recorded only once when trunks notices the write errno is gone after restart. yich@google.com cros-hwsec+uma@google.com Each sample is the result code of a TPM command issued through trunks. For the error codes, see src/platform2/trunks/tpm_generated.h. chingkang@chromium.org cros-hwsec+uma@google.com The write errno changed after rebinding the TPM driver; recorded only once when trunks notices the write errno has changed after restart. chingkang@chromium.org cros-hwsec+uma@google.com The sticky write errno after rebinding the TPM driver; recorded only once when trunks notices the write errno isn't changed after restart. hcyang@google.com cros-hwsec-userland-eng+uma@google.com Records occurrences of U2F commands sent to cr50. hcyang@google.com cros-hwsec-userland-eng+uma@google.com Records the FIPS mode status (whether it is activated) for the Cr50 U2F implementation. This is recorded every time u2fd is started. hcyang@google.com cros-hwsec-userland-eng+uma@google.com Records the FIPS mode status (whether it is activated) for the Cr50 U2F implementation when the U2F mode specified by device policy is {U2FMode}. This is recorded every time u2fd is started. iby@chromium.org chromeos-data-eng@google.com Use time (device ON and not asleep) in a particular period (approximately every five minutes). To compute usage time in a given period (e.g. a day), sum up all reported values of this metric for that period (day). As with other UMA metrics on CrOS, this will be uploaded roughly every half-hour. This will eventually supercede Platform.DailyUseTime, which has significant limitations (e.g. it may not report on the right day). semenzato@chromium.org bsimonnet@chromium.org iby@chromium.org chromeos-data-eng@google.com Count of unclean OS shutdowns during the previous day, or the most recent day the device was in use. Specifically, the counter is incremented during boot if the OS did not shut down cleanly and the previous shutdown was not due to a kernel crash (kernel crashes are counted elsewere) and the previous shutdown did not occur while the device was suspended (failures while suspended are assumed to be the battery running down). Reported at most once a day. semenzato@chromium.org bsimonnet@chromium.org iby@chromium.org chromeos-data-eng@google.com Count of crashes (user) during the previous day, or the most recent day the device was in use. Reported at most once a day. kglund@google.com cros-network-metrics@google.com Sample collected 10s after boot, showing how many WiFi interfaces are present. kglund@google.com cros-network-metrics@google.com Logged (with a constant value of 1) if a WiFi device experienced a PCI failure such that it is being removed from the system. Typically, Chrome OS will follow such a removal with an attempt to rescan the bus and recover device functionality. See also Platform.WiFiStatusAfterForcedPCIRescan for the result of such attempts. kglund@google.com cros-network-metrics@google.com Shows the WiFi status after the PCI bus is rescanned to recover WiFi. The UI depends on shill noticing that wlan0 is back up, so the only happy case is one where shill recognizes wlan0 after the rescan completes. gwendal@google.com chromeos-storage@google.com Number of disk sectors per second written by Chrome OS in a long interval (currently 30s) gwendal@google.com chromeos-storage@google.com Number of disk sectors per second written by Chrome OS in a short interval (currently 1s, sampled every 30s) bgeffon@chromium.org chromeos-memory@google.com Compressed swap size in megabytes. This is the actual amount of RAM used by the system to compress memory (i.e. after compression). Snapshot every 30s. bgeffon@chromium.org chromeos-memory@google.com The ratio of compressed memory (zram) before and after compression when the denominator at least 1 MB. Ratios of interest are between 1 and 6 (typically between 2 and 3), and we express them as a percentage (between 100% and 600%). The size of memory before compression includes zero-filled pages. Values close to 100% indicate low compression effectiveness. Snapshot every 30s. vbendeb@chromium.org ti50-core+uma@chromium.org A histogram of values representing AP RO verification state on ChromeOS devices in the field. The values are collected on each ChromeOS start up and are clustered in two ranges: 0..7 and 20..34, both ranges could grow. Cr50 and Ti50 are two generations of GSC (Google Security Chip), their AP RO verification states are named such that it is clear which particular chip version they refer to. apronin@chromium.org vbendeb@chromium.org cros-hwsec+uma@google.com A sparse histogram of values of Board ID flags programmed in GSC devices in the field. Board ID flags is a 32 bit field, and while there only are a few expected values, conceivably any bit combination could be encountered. vbendeb@chromium.org apronin@chromium.org cros-hwsec+uma@google.com A sparse histogram of values indexed by 4 byte Board ID code programmed in GSC reported by devices where there is a mismatch between the RLZ code and the Board ID value programmed in the GSC. apronin@chromium.org vbendeb@chromium.org cros-hwsec+uma@google.com A histogram of flash log event types collected from the GSC device. Log event type is an 8 bit value. This histogram does not allow to drill into particular log entries' contents, but allows to collect a general statistics of events. A script running on the Chrome OS device polls the GSC for new flash log events after every start up. vbendeb@chromium.org cros-hwsec+uma@google.com A sparse histogram of values indexed by 4 byte Board ID code programmed in GSC, reported by devices where there is no mismatch between the RLZ code and the Board ID value. vbendeb@chromium.org apronin@chromium.org cros-hwsec+uma@google.com A sparse histogram of values indexed by 4 byte RLZ code reported by devices where there is a mismatch between the RLZ code and the Board ID value programmed in the GSC. Since RLZ code could be misprogrammed, a sparse histogram is used to allow keeping track of outliers.