gcp-error-reporting-nodejs

name	gcp-error-reporting-nodejs
description	Set up and use Google Cloud Error Reporting in Node.js applications. Explains when to rely on automatic error capture (Cloud Run / Cloud Run functions) vs the @google-cloud/error-reporting client library, and how to format Cloud Logging entries so Error Reporting ingests them. Use when the user asks about Error Reporting, clouderrorreporting.googleapis.com, reporting Node.js exceptions, configuring @google-cloud/error-reporting, or formatting logs for Error Reporting.
license	MIT
compatibility	["Node.js + npm (when using @google-cloud/error-reporting)","A Google Cloud project with Error Reporting API enabled (when using the client library or APIs)"]
metadata	{"domain":"observability","cloud":"gcp","language":"nodejs","services":["error-reporting","cloud-logging","cloud-run","cloud-run-functions"]}

Google Cloud Error Reporting — Node.js

This skill helps you decide the right Error Reporting ingestion path (automatic capture vs client library vs log formatting), then implement it safely for Node.js apps.

Applicability Gate

Apply this skill when ANY of the following are true:

• You want errors from a Node.js app to appear in Google Cloud Error Reporting
• You are deploying to Cloud Run or Cloud Run functions and want to confirm what is automatic
• You need to report custom errors (not only unhandled exceptions)
• You need to format logs so Error Reporting ingests them from Cloud Logging
• You need to configure @google-cloud/error-reporting (reportMode, serviceContext, auth)

Do NOT apply when:

• You only need to query logs / build Cloud Logging filters → route to gcloud-logging

Routing Table

Question	Route to
“What are the ingestion paths (automatic vs library vs APIs)?”	overview-and-ingestion-paths
“Do I need the Node.js client library on Cloud Run?”	cloud-run
“Do I need the Node.js client library on Cloud Run functions?”	cloud-run-functions
“How do I set up Error Reporting for Node.js?”	nodejs-setup
“How do I configure @google-cloud/error-reporting options?”	nodejs-config quickref
“How do I manually report errors from Node.js?”	nodejs-client-library
“How should I format Cloud Logging entries so Error Reporting ingests them?”	logentry-formatting
“How do I populate the Error Reporting response code for HTTP handlers?”	logentry-formatting
“Which jsonPayload fields does Error Reporting look at?”	logentry fields quickref

Procedure

1. Identify the runtime. Delegate this to an explore subagent to scan the codebase for deployment configs (e.g., app.yaml, Dockerfile, functions framework) to determine if it's Cloud Run, Cloud Run functions, or local dev.
2. Pick the ingestion path.
   • Prefer automatic capture when your runtime already emits unhandled exceptions to Logging.
   • Use @google-cloud/error-reporting when you need manual reporting, framework middleware, or custom grouping/metadata.
   • Use log formatting when you can’t (or don’t want to) use the library, but still control log entry shape.
3. Route to the right reference using the table above (read only what you need).
4. Propose the minimal change set. Output the proposed changes as a strict markdown checklist. Do not include chatty explanations. Keep credentials out of source code.
5. Validate safely. Use a shell subagent to generate a test error (in a non-production environment) and confirm it appears in Error Reporting and/or in Cloud Logging with expected payload shape.
6. Distinguish HTTP from non-HTTP workloads. Only populate Error Reporting HTTP context when the error belongs to an actual HTTP request/response flow.

Confirmation Policy

Do NOT apply code/config changes without explicit user confirmation, especially when:

• Adding dependencies (@google-cloud/error-reporting)
• Changing auth strategy (service account keys, API keys, ADC)
• Enabling reportUnhandledRejections or adding process.on("uncaughtException") handlers

Related Skills

• gcloud-logging — query Cloud Logging and investigate stack traces and error patterns