A first, simple picture before we open the details.

Error Reporting is a Google Cloud service that counts, analyses and aggregates the crashes and exceptions in your running cloud services. In plain words, it is a tidy inbox for application errors. Instead of reading raw log lines, you open a page that lists each distinct problem once, with how many times it happened, how many users it touched, when it first appeared, when it last appeared, and where in the code it came from.

It belongs to Google Cloud’s observability family, the set of tools that help you see what is happening inside your systems. Its neighbours are Cloud Logging for storing log messages, Cloud Monitoring for numbers and alerts, and Cloud Trace for following a request through many services. Error Reporting sits on top of logs: it reads the entries that look like errors and turns them into a structured, human-friendly view.

What it does for you

• Detects errors from logs and from direct reports, with no heavy setup in many environments.
• Groups similar errors so one bug appears as one line, not ten thousand.
• Counts occurrences over time and shows trends in a small chart.
• Shows details such as the stack trace, the service, the version and a sample log entry.
• Notifies you when a new error appears or when a resolved one comes back.
• Tracks status so a team can mark errors as acknowledged, resolved or muted.
• Links each error group to a ticket in your issue tracker so everyone can follow progress.

Why reading raw logs is a poor way to find bugs.

Too much noise

A busy application can write millions of log lines a day. Most are routine messages such as “request received” or “order saved.” A real error is a needle in a haystack. Searching for the word “error” helps a little, but it also finds harmless warnings, expected failures and old problems everyone already knows about.

One bug, a thousand lines

When a bug affects many users, it writes the same failure again and again. Reading ten thousand copies of the same message does not teach you anything the first copy did not. What you really want to know is: how many different problems exist, and which is biggest?

Users do not report most errors

Many people never complain. They close the page, uninstall the app or go to a competitor. Without automatic detection, a team learns about problems only through angry emails or falling revenue, which is slow and costly.

Slow, scattered investigation

Without a central view, developers hunt for the right log, the right time window, the right server and the right version. Valuable minutes disappear while customers wait. Having one place that says “this problem began after yesterday’s release and affects the checkout service” shortens the whole investigation.

The few programming ideas you need before the service makes sense.

What is an error?

When a program is running and meets a situation it cannot handle, such as dividing by zero, reading a missing file or calling a service that does not answer, it raises a signal that something went wrong. In many languages this signal is called an exception. If nothing catches and handles the exception, the program may stop or return a failure to the user. Programmers also use the word error loosely for any such failure.

Handled and unhandled

A handled exception is one the code expects and deals with, for example showing “please try again.” An unhandled exception is a surprise that travels all the way up and crashes the request or the whole program. Error Reporting is most useful for unhandled and unexpected problems, though applications can deliberately report handled ones when they matter.

What is a stack trace?

Programs are made of functions that call other functions. At any moment the running code has a chain of calls, with the newest at the top, a bit like a stack of plates. When an exception occurs, the language can print this chain. That printout is called a stack trace. It lists the files, functions and line numbers that were active, so a developer can see exactly where the failure happened and how the code got there.

flowchart TD
  A["User clicks Place Order"] --> B["checkout function"]
  B --> C["calculate total function"]
  C --> D["apply discount function"]
  D --> E["Failure: discount value is missing"]
  E -.-> F["Stack trace lists D, C, B, A with line numbers"]
    

Reading the diagram

The user’s click starts a chain: checkout calls a total calculation, which calls a discount step, which fails because a value is missing. The stack trace records that chain. A developer reading it sees the failing line first and the story of how the program arrived there behind it. Error Reporting uses this chain as the “fingerprint” of the problem, which is why a good stack trace is so important.

Other terms you will meet

• Log entry: one recorded message, with a time, a severity and a text or structured body.
• Severity: a label such as info, warning or error that says how serious a log entry is.
• Crash: the program stops completely because of an unhandled failure.
• Regression: a problem that was fixed and later returns, often after a new release.
• Release or version: a numbered snapshot of your code that you deploy.

The small vocabulary of the Error Reporting console.

Events versus groups

This pair is the most important idea. An event is a single happening. A group is a family of similar events. If one bug is triggered 5,000 times by 800 users, Error Reporting shows one group with 5,000 occurrences and 800 affected users. You work with groups; the events are the evidence inside them.

Service and version context

Every error is stamped with the service name and version. This stamp is called the service context. It lets you ask useful questions: “Did this error exist before version 2.4?” or “Does it only affect the payments service?” Without it, errors from different applications blur together.

Time windows

The console lets you view errors over different time ranges, such as the last hour, day, week or custom periods, up to the limit of how long the service keeps data. A short window shows what is happening now. A long window shows slow trends and old, quiet problems.

From a failing line of code to a row in the console.

flowchart LR
  APP["Your application: Cloud Run, Functions, App Engine, GKE, VMs"] --> LOG["Cloud Logging"]
  APP -.-> API["Error Reporting API: direct report"]
  LOG --> DET["Error detection: finds exception-like entries"]
  API --> ING["Error Reporting ingestion"]
  DET --> ING
  ING --> GRP["Grouping engine"]
  GRP --> CON["Console: list, details, trends"]
  GRP --> NOT["Notifications"]
  CON --> TEAM["Your team"]
  NOT --> TEAM
    

Reading the diagram

Your application runs on a Google Cloud service. Most of these services send what the program prints, including stack traces, to Cloud Logging automatically. Error Reporting looks at those log entries, recognises the ones that contain an exception or stack trace, and ingests them. Alternatively, your code can call the Error Reporting API directly and hand over an error on purpose. After ingestion, a grouping engine decides which events belong together. The result appears in the console, and notifications can be sent.

The journey in steps

The two roads into Error Reporting.

Road one: automatic capture from logs

Many Google Cloud runtimes forward your program’s output to Cloud Logging without extra work. When a printed message contains a recognisable exception and stack trace, Error Reporting can pick it up. This is the easiest path: for several managed services you may need only to make sure the application logs its exceptions, and that the API is enabled in the project.

Road two: reporting directly

Your code can also send errors on purpose, in one of three ways:

• Client libraries: Google provides libraries for several programming languages that wrap the reporting call, so one line sends an exception along with context.
• The Error Reporting API: any program that can make a secure web request can report an event, including languages without a ready-made library.
• Structured log entries: your logging code can write an entry in a documented shape that includes the message, the service context and the stack trace, and Error Reporting treats it as an error event.

Reporting handled errors on purpose

Sometimes your code catches an exception so a user sees a friendly message, yet the situation is still a bug worth fixing. If nothing reports it, the failure disappears. A good practice is to catch, tell the user kindly, and also report the error so it appears in your list.

Where Error Reporting works, and what it expects from your code.

Google Cloud environments

Languages

Error Reporting understands stack traces from several popular languages, commonly including Go, Java, Node.js, PHP, Python, Ruby and .NET. Each language prints stack traces in its own style, so the service has a recognition rule for each. If your language is not on the list, you can still send structured events with the stack trace as plain text through the API, though automatic recognition may be weaker. The list of supported languages and formats evolves, so confirm it in the official documentation.

Make exceptions look like exceptions

• Log the full stack trace in a single log entry, not split across many lines that reach the logger separately.
• Use the standard exception logging methods of your language and logging library, which print traces in the format expected.
• Avoid trimming or reformatting the trace text before logging it.
• Set severity to error for entries that represent genuine failures.
• Use structured logging with a field for the trace and a field for the service context when possible.

The short setup checklist, in words.

Who can do what

Access is controlled by IAM, Google Cloud’s identity and access management system. Predefined roles exist for the main jobs. Names and exact permissions can change, so confirm the current ones, but the idea is stable:

The two small labels that make errors much easier to understand.

The service context has two parts: a service name and a version. Managed platforms often fill these in for you from their own settings, such as the Cloud Run service name and revision. When you report errors yourself, you should provide them deliberately.

Why they matter

• Separation: errors from the website, the payment system and the nightly job are shown apart, so one noisy component does not hide the others.
• Release tracking: if the version label changes with each deploy, you can see which version first produced an error.
• Responsibility: a service name tells you which team to contact.
• Filtering: the console lets you narrow the list by service and version.

Choosing good names

What you see when you open Error Reporting, and how to read it.

The error list

The first page shows a table of error groups for the selected time range. Each row is one group and typically shows:

• Resolution status: a label such as open, acknowledged, resolved or muted.
• Occurrences: how many events arrived in the time range, often with a small trend chart.
• Users: how many distinct users were affected, if user identifiers are available.
• Error: a short title, usually the exception type and message, plus the place in the code.
• Seen in: the services and versions where it appeared.
• First seen and last seen: when it began and when it last occurred.
• Response: a link to a ticket, if one has been attached.

Above the table you can filter by time, service, version and status, and sort by the columns that matter, such as most recent or most users.

The group details page

Clicking a row opens the group in detail. You will find a larger chart of occurrences, the list of affected services and versions, the status controls, the link field for a ticket, and a section of samples. Each sample is one real event with its full stack trace, and a link that opens the matching log entry in Cloud Logging, so you can see the surrounding messages around the same moment.

How to triage the list in five minutes

The clever part that turns noise into a short list.

Grouping is the service’s most valuable trick. When a new event arrives, Error Reporting compares it with existing groups. Two events are usually considered the same problem when they share the same type of failure and the same essential shape of stack trace, meaning the same functions in the same order, within the same service. Details that change on every occurrence, such as specific numbers in the message, are ignored for this comparison where possible.

flowchart TD
  EV["New error event arrives"] --> N["Normalise: strip changing details"]
  N --> FP["Build a fingerprint from exception type and stack frames"]
  FP --> M{"Matches an existing group?"}
  M -->|"Yes"| ADD["Add to group: update counts, last seen, users"]
  M -->|"No"| NEW["Create new group: mark first seen, may notify"]
  ADD --> UI["Console shows updated group"]
  NEW --> UI
    

An illustration

Suppose the message says “Order 1001 not found” for one user and “Order 2093 not found” for another. A good grouping step recognises these as the same problem with different numbers, and puts them in one group. If two different functions each fail with a missing value, they have different stack traces and form two groups, even if the words look similar.

When grouping goes wrong

• Over-splitting: one bug appears as many groups, often because the stack trace differs slightly, for example when it contains generated code names or random identifiers.
• Over-merging: different bugs share a group because they pass through the same shared helper function that appears at the top of both traces.
• Missing traces: events without a stack trace are grouped by the message alone, which can be crude.

How to improve grouping

A shared way for a team to say who is handling what.

Each error group has a resolution status that the team can change. These labels turn the list into a simple workflow board.

stateDiagram-v2
  [*] --> Open: New error group appears
  Open --> Acknowledged: Someone takes ownership
  Acknowledged --> Resolved: Fix is released
  Open --> Muted: Known and accepted
  Acknowledged --> Muted: Decided not to fix
  Resolved --> Open: Error returns after the fix
  Muted --> Open: Team un-mutes it
    

Good habits for the workflow

• Mark a group resolved only after the fix is deployed, not when the code is merged.
• Add a note or ticket link whenever you acknowledge, so colleagues know who is on it.
• Review muted groups on a schedule. A muted group can hide a growing problem.
• Keep the open list short. A list of hundreds of ignored open groups is no longer useful.
• Agree a team rule: how long may an open group wait before someone must look at it?

Turning a detected error into tracked, assigned work.

Each error group has a field where you can attach a link to a ticket in your issue tracker. This link appears in the list, so anyone can tell at a glance whether a problem has an owner. The tracker can be any system that has web addresses for issues, such as Jira, GitHub Issues, GitLab, Linear or an internal tool.

A typical flow

Sharing outside the console

• Each group has its own web address that you can paste into chat messages, tickets and incident notes.
• Colleagues need viewer access to open it, so combine sharing with appropriate roles.
• Teams often add the group address to deployment notes, so reviewers can check whether a release reduced the error.

How Error Reporting reaches out to people.

Nobody wants to refresh a web page all day. Error Reporting can send notifications when something worth attention happens. The usual triggers are a new error group appearing, or a resolved group reappearing, because both suggest a change in behaviour rather than ordinary background noise.

Typical channels

Controlling the noise

• Send notifications for production projects only, not for every test project.
• Use the acknowledged and muted statuses to reduce repeats once a group is being handled.
• Let on-call people receive urgent alerts, and let others read a daily summary.
• Review who is subscribed whenever people join or leave the team.

When you need rules more precise than “a new error appeared”.

Error Reporting’s own notifications are simple. For richer control, teams use Cloud Monitoring. A log-based metric counts log entries that match a filter, for example entries with error severity from the checkout service. Monitoring can chart that count over time and raise an alert when it crosses a threshold, such as more than fifty errors in five minutes.

flowchart LR
  LOGS["Cloud Logging: error entries"] --> LBM["Log-based metric: count matching entries"]
  LBM --> MON["Cloud Monitoring chart"]
  MON --> POL["Alert policy: threshold and duration"]
  POL --> CH["Notification channels: email, chat, pager"]
  LOGS --> ER["Error Reporting groups and details"]
  CH --> ONC["On-call engineer"]
  ONC --> ER
    

When to use which

Alert design tips

• Alert on user impact, such as an error rate, rather than on any single error.
• Use a duration, so a one-minute blip does not wake anyone.
• Include a link to the Error Reporting list in the alert’s documentation text.
• Test alerts by simulating a failure in a non-production project.

Four observability tools, each answering a different question.

flowchart TD
  P["Production problem"] --> M["Monitoring: Is something wrong, and how big?"]
  M --> E["Error Reporting: Which errors, where in the code?"]
  E --> L["Logging: What happened around that moment?"]
  L --> T["Trace: Which request path and which service was slow or failing?"]
  T --> F["Fix, deploy, verify"]
    

Practical links between them

• From an Error Reporting sample, jump to the exact log entry in Cloud Logging.
• If your logs include a trace identifier, you can open the same request in Cloud Trace.
• Use log-based metrics to feed counts of matching errors into Monitoring charts and alerts.
• Put an Error Reporting widget or link on the same dashboard as your key service metrics.

Habits for developers that make the console far more useful.

Do not report everything

Not every exception is a bug. A user typing a wrong password is a normal event. A missing page requested by a web crawler is expected. If your code reports these as errors, the real problems drown in noise. Decide which situations deserve a place in the error list, and log the rest at a lower severity or count them as metrics instead.

Global handlers as a safety net

Most frameworks let you register a single place that catches any exception nobody else handled. Connect that place to your error reporting, so even surprising failures are reported with the right service context. Then add specific reporting for important handled cases.

Batch jobs and background work

Scheduled tasks and queue workers have no user looking at a screen. If they fail quietly, nobody knows. Make sure their exceptions flow into the same error list, with a service name that makes clear which job failed, and consider an alert if an expected job does not run at all.

Using error data to judge whether a new version is healthy.

Every release is a small gamble. Error Reporting lets you check the result quickly. After deployment, compare the new version’s errors with the old one: Are there new groups whose first-seen time matches the deploy? Has an old group grown? Did a group you meant to fix disappear?

sequenceDiagram
  participant D as Developer
  participant P as Pipeline
  participant S as Service v2
  participant E as Error Reporting
  D->>P: Merge change
  P->>S: Deploy small share of traffic
  S->>E: Report any new errors with version v2
  D->>E: Check new groups and counts for v2
  alt Healthy
    D->>P: Increase traffic to v2
  else Unhealthy
    D->>P: Roll back to v1
  end
  D->>E: Mark fixed groups as resolved
    

Regression watch

A regression is a bug that returns. Because a resolved group reopens when it occurs again, the console becomes an automatic regression detector. Together with version labels, you can see exactly which release brought the problem back.

A release checklist

Error messages and stack traces can leak more than you expect.

What can leak

• Personal data in messages, such as names, emails or phone numbers from a failed form.
• Secrets in error text, such as connection strings, tokens or passwords that appear in a failed request.
• Internal details such as file paths, server names and library versions in stack traces.
• Business data embedded in a query or payload that is printed when it fails.

Because errors are stored and shown to many team members, anything printed into them becomes widely visible and long-lived. This matters under privacy laws and company rules.

Protection measures

How long errors stay, and what happens when volumes grow.

Error Reporting does not keep data forever. Error events are retained for a limited period, commonly described as about thirty days, after which old events fall away from the view. Exact numbers can change, so confirm in the documentation. Error groups with recent activity remain visible, while very old, inactive ones eventually disappear.

Why this matters

• If you need to analyse trends over many months, export the underlying logs to storage or BigQuery, where you control the retention.
• For audits, keep your own record of significant incidents, not only the console view.
• When investigating an old incident, you may find the stack trace gone from Error Reporting but still present in Cloud Logging, depending on log retention settings.

Scaling and limits

An error storm

A single failing dependency can make every request fail at once, creating millions of events in minutes. This is called an error storm. Grouping keeps the console readable, but your reporting code and quotas still feel the load. Guard against storms by rate limiting reports from one process, and by using circuit breakers that stop calling a broken dependency for a while.

Understanding where the money may go.

Error Reporting itself has historically been offered without a separate charge, but nearby services may cost money. In particular, the log entries that carry your errors are stored in Cloud Logging, which has its own pricing for ingested and retained data above free allowances. Alerts and metrics in Cloud Monitoring can also have costs, and calling an API from outside can add network charges. Pricing changes, so always check the current pricing pages.

Habits that keep it economical

What to check when you expect an error and the console shows nothing.

flowchart TD
  S["Expected error not shown"] --> A{"Is the API enabled in this project?"}
  A -->|"No"| A1["Enable it"]
  A -->|"Yes"| B{"Does the error appear in Cloud Logging?"}
  B -->|"No"| B1["Fix logging: agent, permissions, exclusion filters, severity"]
  B -->|"Yes"| C{"Is it one log entry with a full stack trace?"}
  C -->|"No"| C1["Fix log format: single entry, standard exception logging"]
  C -->|"Yes"| D{"Is the time range and filter in the console correct?"}
  D -->|"No"| D1["Widen time range, clear service and status filters, include muted"]
  D -->|"Yes"| E["Check reporting identity permission, API quotas and retention"]
    

A simple, repeatable routine for handling errors every day.

Tools help only when people use them consistently. A short playbook keeps everyone in step, especially for teams that rotate on-call duty.

Daily routine

1. Open the list for production, last twenty-four hours, sorted by affected users.
2. Check for new groups first. Each one needs a decision: fix now, schedule, or accept.
3. Check for reopened groups, which mean a regression.
4. For the top three by impact, make sure each has an owner and a ticket.
5. Review muted groups weekly for any that have grown.

Severity guide

Following an imaginary online shop through one real-looking incident.

“Lotus Home” is an imaginary online kitchenware shop. On Tuesday at 10:05 the team releases version 3.8 of its checkout service on Cloud Run. By lunchtime, sales are a little lower than usual, but no customer has complained. Here is how Error Reporting helps.

sequenceDiagram
  participant C as Customer
  participant S as Checkout v3.8
  participant L as Cloud Logging
  participant E as Error Reporting
  participant T as Team
  C->>S: Place order with promo code
  S->>S: Discount value missing, exception raised
  S->>L: Log exception with stack trace
  L->>E: Error entry detected
  E->>E: New group created for version 3.8
  E->>T: New error notification
  T->>E: Open group, read stack trace and samples
  T->>S: Deploy fix as v3.9
  T->>E: Mark group resolved
    

An honest balance sheet before you rely on it.

Key trade-offs

Habits that help, and habits that hurt.

Helpful patterns

Anti-patterns to avoid

A checklist you can use from your first day.

Best practices

• Enable the API and confirm that logs reach Cloud Logging in every production project.
• Set clear service names and release-based version labels everywhere.
• Log full exceptions in a single, standard-format entry.
• Keep messages stable and move changing values into separate fields.
• Report handled errors that still represent bugs, and skip purely expected events.
• Give console access by role, and keep application identities write-only.
• Agree who triages, how often and what counts as critical.
• Use Cloud Monitoring alerts on error rates for urgent cases.
• Link every acknowledged group to a ticket with an owner.
• Scrub sensitive data before it is logged.
• Export logs if you need long-term history.
• Verify current features, limits and prices in official documentation.

Common mistakes

• Using a constantly changing value as the version label.
• Mixing test and production errors in one project.
• Splitting stack traces across many log entries.
• Treating the notification email as the whole process.
• Marking groups resolved before the fix is actually deployed.
• Letting open groups pile up until nobody trusts the list.
• Expecting Error Reporting to catch silent logic bugs that raise no exception.
• Forgetting background jobs and scheduled tasks.

Illustrative ways teams typically use Error Reporting.

A short set of questions to decide how to use it in your own project.

flowchart TD
  S["Your application runs on Google Cloud?"] -->|"Yes"| A{"Do exceptions with stack traces reach Cloud Logging?"}
  S -->|"No, elsewhere"| X["Use client libraries or the API with credentials"]
  A -->|"Yes"| B["Enable the API and watch the console"]
  A -->|"No"| C["Fix logging format or report errors directly from code"]
  B --> D{"Need alerts on error volume?"}
  X --> D
  C --> D
  D -->|"Yes"| E["Add log-based metrics and Monitoring alert policies"]
  D -->|"No"| F["Use new-error notifications and daily triage"]
  E --> G["Agree owners, statuses and a triage routine"]
  F --> G
    

Questions to ask your team

• Who will read the list? A tool nobody reads is only a cost. Name a person or a rota.
• What counts as an error here? Decide in advance which events deserve a place in the list, and which are normal.
• How will we tell versions apart? Agree a version label that changes with each release and stays stable between releases.
• What may be written in messages? Set a simple rule for sensitive data, and check it in code review.
• How fast must we respond? Link response times to severity levels, so urgent and non-urgent errors are treated differently.
• How long must we keep history? If longer than the service retains, plan a log export.

Quick definitions of the words used in this guide.

Often not. On many managed Google Cloud services, exceptions written to the logs with a stack trace are detected automatically. For more control, use client libraries, the API or structured log entries.

Yes, applications elsewhere can report through the API or client libraries with suitable credentials and a Google Cloud project to receive the errors.

Logging stores every message. Error Reporting extracts the failures, groups them, counts them and tracks their status. Think of logging as the archive and Error Reporting as the summarised front page.

Monitoring watches numbers and alerts on thresholds. Error Reporting explains which specific errors exist and where in the code they happen. Use them together.

Usually because messages contain changing values or stack traces differ slightly. Keep messages stable and put variable details in separate fields.

The group returns to open, and a notification can be sent, which helps you catch regressions.

For a limited time, commonly around thirty days of event data. Export logs if you need longer history, and confirm the current retention period in the documentation.

The service has typically been offered without a separate fee, but logging, monitoring and network usage around it can cost money. Check current pricing pages.

Error Reporting is mainly designed for server-side applications. For mobile apps and browsers, dedicated crash reporting tools are usually better; check current guidance for your platform.

Yes, through Cloud Monitoring notification channels connected to alert policies, and sometimes through other integrations. Configure them according to the current documentation.

Fix the code so the data is not logged, restrict access to the affected project, and ask your security team about deleting the exposed entries according to your policy.

The whole guide in one short page.

Error Reporting turns the raw noise of application failures into a short, prioritised list of distinct problems. It collects exceptions from Cloud Logging or directly through its API, groups the repeats using the shape of the stack trace, counts occurrences and affected users, and labels each problem with the service and version where it appeared. Statuses, ticket links and notifications turn the list into a shared workflow, while Cloud Monitoring adds precise alerts. The service works best when your code logs full exceptions in standard formats, names its services and versions sensibly, keeps sensitive data out of messages, and when a team reviews the list on a regular routine.