Runtime logs

Whatever your code prints while it runs is captured line by line and shown next to the request that caused it. Read runtime logs when a response was wrong and you need to know what your code was doing at the time.

What is captured

Each line a Function writes to standard output or standard error becomes one record carrying the stream it came from and the time it was written. In a JavaScript Function, console.log, console.info and console.debug are recorded as stdout, while console.warn and console.error are recorded as stderr.

Lines written through console also carry the id of the request being handled. Gigadrive Network keeps that id in scope for the whole invocation, so a line printed from an awaited call still lands on the right request. Output written straight to the file descriptors, by a logging library that calls process.stdout.write or by a subprocess, arrives with no request attached.

Two limits apply to the capture itself. One line is stored up to 16,384 characters and cut there. Under a burst, up to 4,096 lines are buffered, and once that buffer is full the lines arriving next are discarded rather than slowing your code down. A Function printing tens of thousands of lines a second loses some of them.

Where it appears

Open an environment in the console and select Logs. That view merges runtime output with Request logs. A line correlated to a request is folded into that request's row, which shows how many lines the request produced, how many of them were stderr, and the most recent message; opening the row shows the full output. Lines with no request appear as entries of their own.

The filter panel narrows by activity kind, stream, deployment, function, and a time range between the past 30 minutes and the past 7 days. Search matches a substring of the message, and on request rows also the hostname, path and query.

What never reaches your logs

The platform writes one accounting line at the end of every invocation, and that line is filtered out before storage. The filter matches the literal marker "event":"gd.invocation", so a line of your own output containing that string is dropped along with it.

How long they are kept

Runtime logs are deleted 30 days after they are written. There is no setting that extends or shortens that window. Deleting a Function or a deployment does not delete its logs: they stay readable and age out on the same schedule.

Tailing output as it happens

The activity stream carries runtime lines as well as requests, so filtering it to kind=runtime gives you a live tail of output alone. This example narrows it further to stderr, which is the stream you want open while reproducing a failure.

curl -N \
  -H "Authorization: Bearer $GIGADRIVE_TOKEN" \
  -H "Accept: text/event-stream" \
  "https://api.gigadrive.network/applications/0197b2f1-2f4a-7a0b-8a2d-222222222222/logs/stream?kind=runtime&streams=stderr"

The token needs the network:requests:read scope; see Authentication. Each line arrives as an item event, and the stream closes with an end event once it reaches its time budget. Request logs covers the event catalogue, the resume rules and the per-credential stream limits.