shaktisahu@chromium.org src/components/minidump_uploader/OWNERS Records the time (uptimeMillis) taken by a minidump uploading task to complete. Recorded when the task finished callback is invoked. Removed in M111. boliu@chromium.org ssid@chromium.org Records the reverse rank of a child process when it is killed by android if applicable. Chrome on Android ranks some child processes and provides hints to android that it should kill from lowest to highest ranked. The lowest ranked process has reverse rank 0. This is a measure how good the hints to android are; if hints were perfect, then all android kills should have reverse rank 0. boliu@chromium.org ssid@chromium.org wnwen@chromium.org Individual enum counts specific conditions of child process terminations. There are too many individual states to enumerate into a single histogram, so this effectively does the aggregration that normally happens on the server side in the client instead. The benefit is this is easily extensible in the future, and downside is that it does not allow additional server side analysis. Note a single child process termination may fall into multiple enums. wnwen@chromium.org src/components/minidump_uploader/OWNERS Records the number of non-simulated minidumps processed by Crashpad, split by process type. This metric is similar to one that could be computed server-side based on received crash uploads; but the client-side metric also includes any minidumps that were not successfully uploaded. wnwen@chromium.org Counts renderer crashes including OOMs. Android only. Mirrors old stability proto renderer crashes. boliu@chromium.org ssid@chromium.org wnwen@chromium.org Reason given by Android ActivityManager for the exit of the process, only recorded in Android R+. Recorded on the next browser startup for browser exits, or right after the process died for child processes. vollick@chromium.org battre@chromium.org Count of processes killed because they sent a bad IPC that couldn't be properly handled. Categories are the reasons (code locations) for the kills. creis@chromium.org jamescook@chromium.org Count of processes killed by chrome/browser because they sent an IPC that couldn't be properly handled. Categories are the reasons (code locations) for the kills. jam@chromium.org jamescook@chromium.org Count of child processes killed because they sent an IPC that couldn't be properly handled. Categories are the reasons (code locations) for the kills. rdevlin.cronin@chromium.org extensions-core@chromium.org Count of extension processes killed because they sent an IPC that couldn't be properly handled. Categories are the reasons (code locations) for the kills. mcnee@chromium.org wjmaclean@chromium.org Count of processes killed because they sent a bad IPC that couldn't be properly handled. Categories are the reasons (code locations) for the kills. Warning: this histogram was expired from M85 to M97; data may be missing. creis@chromium.org jamescook@chromium.org Count of processes killed because they sent a NaCl IPC that couldn't be properly handled. Categories are the reasons (code locations) for the kills. Warning: this histogram was expired from 2020-11-01 to 2021-12-07; data may be missing. creis@chromium.org jamescook@chromium.org Count of processes killed because they sent a bad IPC that couldn't be properly handled. Categories are the reasons (code locations) for the kills. Warning: this histogram was expired from M85 to M97; data may be missing. siggi@chromium.org chrome-stability-core@google.com Records the exit code of the browser process (on Windows) from the previous launch. On crash, the exit code will indicate the exception code of the crash. This is emitted in stability data with the first report on a subsequent launch. Note: Due to https://crbug.com/805754, the enum labels for RESULT_CODE_* are off by 1 for M56 and earlier. alexmos@chromium.org boliu@chromium.org lukasza@chromium.org Logs the reason that a crashed subframe was shown. Logged at most once per crash, and only if the subframe was hidden when it crashed and became visible later. alexmos@chromium.org boliu@chromium.org Logs whether or not a tab is marked for reload when a cross-process subframe crashes. Logged once per subframe process crash. alexmos@chromium.org boliu@chromium.org Logs the visibility of a subframe when a subframe process crashes and the corresponding tab is marked for reload. This indicates whether the crashed subframe was visible or scrolled out of view at the time of crash. alexmos@chromium.org boliu@chromium.org lukasza@chromium.org Logged after detecting that a sad subframe is shown (logged at most once per crash). rkaplow@chromium.org src/base/metrics/OWNERS chrome-analysis-team@google.com Collects various counters related to stability. The majority of them are crash types. nasko@chromium.org altimin@chromium.org Logged at the time when a complex debugging scenario is encountered. The enum value is the type of scenario encountered. This metric will give us two benefits: 1. It will tell us the magnitute of the scenario being debugged since crash reports are throttled client side and cannot presently expess magnitude. 2. If the client is configured to report traces based on this metric, it will upload Chrometto trace for analysis by developers. dcheng@chromium.org wfh@chromium.org adkushwa@microsoft.com Keeps a count of number of times uploading the dump was throttled when calling DumpWithoutCrashing. fdoray@chromium.org catan-team@chromium.org Counts "pageloads" by type. This is recorded when a page stops loading, i.e. from WebContentsObserver::DidStopLoading. The sum of all buckets of this histogram should be equal to the "Total pageloads" shown on Stability dashboards and can be used to diagnose changes to this value. michaelbai@chromium.org src/base/metrics/OWNERS The number of unsent files. Emitted when the stability is recorded. michaelbai@chromium.org src/base/metrics/OWNERS The total number of samples that will be lost if ASSOCIATE_INTERNAL_PROFILE hasn't been enabled since the previous stability recorded. This is different than the previous browser run because one file was just uploaded before the stability is recorded. davidbienvenu@chromium.org jessemckenna@google.com Number of times a browser crash was detected, where the browser was last known to be alive in a Windows system session that terminated abnormally. justincohen@chromium.org olivierrobin@chromium.org Records whether Crashpad init was successful. Recorded on every app startup. ajuma@chromium.org olivierrobin@chromium.org Recorded when iOS app has started after a crash caused by system signal or hang. Not recorded when app has started after UTE / XTE or started after Chrome update. See go/bling-stability-101 for information about signal crashes, hangs, UTEs and XTEs. This metric intends to complement Stability.Counts. Stability.Counts does include UTEs / XTEs and thus is a noisy metric which significantly overcounts user-visible crashes. Stability.IOS.Experimental.Counts2 is not recorded on OOM crashes, so it does not represent all user-visible crashes, but OOMs are so rare in Chrome for iOS that Stability.IOS.Experimental.Counts2 is still a good proxy for user-visible crashes. IOS.MetricKit.ForegroundExitData includes OOM crashes (iOS 14 and higher) and can be used in conjunction with this metric. justincohen@chromium.org ajuma@chromium.org Recorded when the app is foregrounded. Records what action is taken after an unclear shutdown (likely a crash). ajuma@chromium.org justincohen@chromium.org The number of tabs opened in the previous session when the app starts after {Event}. Can be used to understand if there is a correlation between increase of number of tabs and decline in stability. iOS Only. olivierrobin@chromium.org ajuma@chromium.org Recorded on iOS when applicationWillTerminate callback is called when app is in the foreground. When this happens the app will not write clean exit beacon and shutdown will not be clean. michaeldo@chromium.org olivierrobin@chromium.org Number of kilobytes available for "important" data. When an iOS device is critically low on space, actions generally assumed to succeed can fail. In extreme cases, this could potentially include writing the "unclean shutdown" bit to signal a clean shutdown. Logged on application launch if the last session terminated in an unclean state. michaeldo@chromium.org olivierrobin@chromium.org The last known battery charge before a crash occurred. This will only be logged for devices which were last known to be in the "unplugged" state because the intention is to identify devices which may have died leading to unexpected terminations. Logged on application launch if the last session terminated in an unclean state. michaeldo@chromium.org olivierrobin@chromium.org The thermal state of the device when a crash occured. Logged on application launch if the last session terminated in an unclean state. michaeldo@chromium.org olivierrobin@chromium.org Indicates whether or not one of the Stability.iOS.UTE.* metrics could explain the cause of the UTE which terminated the previous session. Logged on application launch if the last session terminated in an unclean state. justincohen@chromium.org olivierrobin@chromium.org Recorded when app starts after Unexplained Termination Event (UTE) or Explained Termination Event (XTE). Values other than Active indicate that prefs::kLastSessionExitedCleanly was not properly stored. michaeldo@chromium.org olivierrobin@chromium.org Recorded when app starts after Unexplained Termination Event (UTE) or Explained Termination Event (XTE). UTEs/XTEs can happen when app did not finish writing prefs. This histogram should help to understand if prefs did not get written during normal app termination sequence when ApplicationWillTerminate notification was called. olivierrobin@chromium.org sdefresne@chromium.org Recorded when app starts after Unexplained Termination Event (UTE) or Explained Termination Event (XTE). UTEs/XTEs can be caused by large memory allocations and this histogram provides information which memory heavy operation has being performed before UTE/XTE. olivierrobin@chromium.org michaeldo@chromium.org true if OS was restarted after the previous session. Logged on application launch if the last session terminated in an unclean state. If this is false then UTE was not caused by OS restart or shutdown. michaeldo@chromium.org olivierrobin@chromium.org Logged on the session following a crash with the result of a comparison between the OS version of the session which crashed and the current OS version. Logged on application launch if the last session terminated in an unclean state. michaeldo@chromium.org olivierrobin@chromium.org The estimated amount of time between when a crash occurred and when the user relaunched the application. Logged on application launch if the last session terminated in an unclean state. michaeldo@chromium.org olivierrobin@chromium.org Type of the shutdown. This histogram is recorded at startup and logs a sample for the previous session. A clean shutdown is one where the app enters the background before being killed. Other shutdowns are all some sort of crash. The absence of a crash log indicates that the app was killed by the OS, normally due to memory pressure. If memory pressure is extremely high, the app may not have had a chance to response to a memory warning before being killed. For first launch after upgrade, the crash reports may be discarded before this histogram is written to so it's not possible to determine if there's a valid crash log present or not. justincohen@chromium.org ajuma@chromium.org Type of the shutdown. This histogram is recorded after processing Crashpad intermediate dumps, and is otherwise identical to Stability.MobileSessionShutdownType, which is recorded at startup and before Crashpad dumps are processed. Because this histogram is not recorded in time for the initial stability log, the histogram will appear in a log that lists the current Chrome version (and other browser metadata), not the Chrome version at the time the crash occurred. The earlier histogram Stability.MobileSessionShutdownType should be in the stability log, which will list the Chrome version at the time of the crash.