Build and runtime logs

Both are on the deployment's page in Cloud and need the logs:read scope, which every role has. Cloud → Logs and a project's Logs tab show runtime logs too, for a deployment you choose (the current production deployment first).

Build logs

The Build logs tab shows the build's output from the first step marker (::step source) on, up to 2,000 lines. The page refreshes itself while the deployment is building. See The build pipeline for the steps.

Runtime logs

The Runtime logs tab shows what the deployment's server function logged in the last hour, newest first, up to 500 lines. Static deployments have no server function and no runtime logs.

• Filter matches messages case-insensitively (up to 200 characters).
• Refresh loads the latest lines.
• When more lines in the hour match than fit, the tab says it's showing the latest ones.

Levels

Each line gets a level, from the first of these that applies:

1. Lambda's own lines (START, END, REPORT, INIT_START and similar) are platform lines, shown without a level.
2. JSON messages with a level, severity or lvl field use it: error, err, fatal, critical, crit, alert, emerg and emergency are errors; warn and warning are warnings; debug, trace and verbose are debug; anything else is info. Numeric pino levels map too (50 and up error, 40 warn, 30 info, below that debug).
3. Otherwise the Node.js log level applies: console.error is an error, console.warn a warning, console.debug and console.trace debug, and console.log info.

Messages longer than 4,000 characters are cut and marked.

Structured logs read well here:

console.log(JSON.stringify({ level: "warn", msg: "payment.retry", orderId, attempt }))

Planned

• Live tail and ranges longer than an hour. Coming soon