Formatting errors in Stackdriver Logging

Before you begin

If using the Stackdriver Error Reporting API, you can report error events from your application by writing them to ReportedErrorEvent. Doing this generates log entries with properly formatted error messages in Stackdriver Logging. The resulting log name is formatted as projects/<PROJECT_ID>/

You might incur minor Stackdriver Logging ingestion costs using this method; to control these costs, review Logs exclusions.

If you prefer to use Stackdriver Logging to report error events, read the following sections.

Formatting requirements

Log entries in Stackdriver Logging that contain stack traces or exceptions, or that are formatted like ReportedErrorEvent, generate errors in Stackdriver Error Reporting.

Error data should be logged as a multi-line textPayload or in the message field of jsonPayload; go to the LogEntry reference for further details. Note that you must also follow the setup instructions for your language and platform.

When logging error data from App Engine, Compute Engine, and Google Kubernetes Engine, the only requirement is that the log entry contains the full error message and stack trace.

JSON representation

When sending error data using Stackdriver Logging, error data must follow this JSON structure:

  "eventTime": string,
  "serviceContext": {
    "service": string,     // Required.
    "version": string
  "message": string,       // Required. Should contain the full exception
                           // message, including the stack trace.
  "context": {
    "httpRequest": {
      "method": string,
      "url": string,
      "userAgent": string,
      "referrer": string,
      "responseStatusCode": number,
      "remoteIp": string
    "user": string,
    "reportLocation": {    // Required if no stack trace in 'message'.
      "filePath": string,
      "lineNumber": number,
      "functionName": string

Supported monitored resource types

Error data logged to Stackdriver Logging is automatically processed if the log entry belongs to a supported monitored resource type and is formatted correctly.

When logging via the LogEntry structure, the resource field must be set to one of the following supported resource types:

  • app_script_function
  • aws_ec2_instance
  • cloud_function
  • consumed_api
  • container
  • dataflow_step
  • gae_app
  • gce_instance
  • k8s_container
  • ml_job
  • global


The following payloads will be correctly processed by Error Reporting if sent to the Stackdriver Error Reporting API or logged in LogEntry.jsonPayload:

Payload with message containing a stack trace:

  "serviceContext": {
    "service": "frontend",
    "version": "bf6b5b09b9d3da92c7bf964ab1664fe751104517"
  "message": "$CartDiv retrieveCart: Error\njava.lang.IndexOutOfBoundsException: Index: 4, Size: 4\n\tat java.util.ArrayList.rangeCheck(\n\tat java.util.ArrayList.get(\n\tat\n\tat\n\tat$CartDiv.retrieveCart(\n\tat\n\tat\n\tat javax.servlet.http.HttpServlet.service(\n",
  "context": {
    "httpRequest": {
      "method": "GET",
      "url": "",
      "responseStatusCode": 500
    "user": "9f32f587135aa6774e78ed30fbaabcce3ec5528f"

Payload with message without stack trace, reportLocation is required:

  "serviceContext": {"service": "worker"},
  "message": "Cannot process job: Missing attribute 'userId'",
  "context": {
    "reportLocation": {
      "filePath": "cleanup.js",
      "lineNumber": 42,
      "functionName": "processJob"

Find more troubleshooting commands on the Support & Troubleshooting page.


Field name Type Description Notes
eventTime string

Time when the event occurred as provided in the error report. If the report did not contain a timestamp, the time the error was received by Error Reporting system is used.

A timestamp in RFC 3339 UTC "Zulu" format, accurate to nanoseconds. Example: "2014-10-02T15:01:23.045123456Z".

serviceContext object The service context for which this error was reported. Required
serviceContext.service string

An identifier of the service, such as the name of the executable, job, or Google App Engine service name. This field is expected to have a low number of values that are relatively stable over time, as opposed to version, which can be changed whenever new code is deployed.

serviceContext.version string Represents the source code version that the developer provided, which could represent a version label or a Git SHA-1 hash, for example. If the developer did not provide a version, the value is set to default. For App Engine standard environment, the version is set to the version of the app. Optional
message string The error message.
If no `context.reportLocation` is provided, the message must contain a header (typically consisting of the exception type name and an error message) and an exception stack trace in one of the supported programming languages and formats.
Supported languages are Java, Python, JavaScript, Ruby, C#, PHP, and Go.
Supported stack trace formats are:
context object Data about the context in which the error occurred. Optional
context.httpRequest object The HTTP request which was processed when the error was triggered. Optional
context.httpRequest.method string The type of HTTP request, such as GET, POST, etc. Optional
context.httpRequest.url string The URL of the request. Optional
context.httpRequest.userAgent string The user agent information that is provided with the request. Optional
context.httpRequest.referrer string The referrer information that is provided with the request. Optional
context.httpRequest.responseStatusCode number The HTTP response status code for the request. Optional
context.httpRequest.remoteIp string The IP address from which the request originated. This can be IPv4, IPv6, or a token which is derived from the IP address, depending on the data that has been provided in the error report. Optional
context.user string The user who caused or was affected by the crash. This can be a user ID, an email address, or an arbitrary token that uniquely identifies the user. When sending an error report, leave this field empty if the user was not logged in. In this case the Error Reporting system will use other data, such as remote IP address, to distinguish affected users. See affected_users_count in ErrorGroupStats. Optional
context.reportLocation object The location in the source code where the decision was made to report the error, usually the place where it was logged. For a logged exception this would be the source line where the exception is logged, usually close to the place where it was caught. Optional
context.reportLocation.filePath string The source code filename, which can include a truncated relative path, or a full path from a production machine. Optional
context.reportLocation.lineNumber number 1-based. 0 indicates that the line number is unknown. Optional
context.reportLocation.functionName string Human-readable name of a function or method. The value can include optional context like the class or package name. For example, my.package.MyClass.method in case of Java. Optional
Was this page helpful? Let us know how we did:

Send feedback about...

Stackdriver Error Reporting Documentation