Runtime logs
What your Functions write to standard output and standard error, where it appears, and how long it is kept.
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. A line longer than 16,000 bytes is cut there and ends with
[truncated]; for plain ASCII text that is 16,000 characters.
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.
Containers and sidecars
A container Function records each line its process writes to standard output or standard error exactly as written. Those lines carry no request id, so they appear as entries of their own instead of on the request that caused them.
Each line a sidecar writes is labeled with the sidecar's name, so redis output is easy to tell apart
from your Function's own. Gigadrive Network also writes a line to stderr when a sidecar or your
container's process exits, is restarted, or cannot be started, for example
Sidecar redis exited with code 1; restarting in 0.4 s. When a sidecar keeps crashing, a final line
says it will not be started again, and the copy of your Function it runs in is replaced.
A Function on a managed runtime gets the same lines when its process ends unexpectedly. A line such as
Your function's process was stopped by signal SIGKILL (possibly out of memory); restarting in 0.2 s
tells you why requests failed and that a restart follows. If the process keeps exiting without staying up,
a final line says it will not be started again and that requests fail until it is replaced. A graceful
shutdown writes nothing.
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. When your application runs sidecars, it also narrows by source: Function for your Function's own output, or the name of a sidecar. Search matches a substring of the message, and on request rows also the hostname, path and query.
What never reaches your logs
This section applies to Functions built from your source files, not to container Functions. 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.
Keep anything you need beyond 30 days
Ship what you need to retain to your own log destination from inside the Function. Nothing in the console preserves output past the retention window.
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.
