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 Serverless App Service'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, newest first, 500 lines at a time. Static deployments have no server function and no runtime logs.

• Range: the last hour (default), 6 hours, 24 hours or 7 days. Function logs are kept for at least 7 days.
• Filter matches messages case-insensitively (up to 200 characters).
• Load older events continues past the first 500 lines.
• Live adds new lines every 3 seconds, newest on top, until you pause it. A very busy function can log more than one request carries; the tab then says some lines were skipped.
• Refresh loads the latest lines.

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 }))