Read the logs
In the console
Open an instance and select the Logs tab. The view holds the most recent output from the container, refreshes every few seconds while the tab is open, and scrolls to the newest line as it arrives. Before the instance has ever reached running there is nothing to show and the panel says so.
What you get is the boot record and whatever the container has printed since:
[2026-07-24 09:12:03] superheat-agent: pulling image pytorch/pytorch:2.4.0-cuda12.4-cudnn9-runtime
[2026-07-24 09:12:07] superheat-agent: image ready, creating container
[2026-07-24 09:12:09] nvidia-smi: detected 2 GPU(s), driver 570.86
[2026-07-24 09:12:10] sshd: listening on 0.0.0.0:40123
[2026-07-24 09:12:11] superheat-agent: instance is ready
This is the first place to look when an instance reaches error, when JupyterLab does not come up, or when an onstart script did not do what you expected.
Over the API
These examples use $SUPERHEAT_API and $SUPERHEAT_KEY — set them as shown in the
API overview.
curl -H "Authorization: Bearer $SUPERHEAT_KEY" \
"$SUPERHEAT_API/v1/instances/$INSTANCE_ID/logs?tail=500"
{
"lines": [
"[2026-07-24 09:12:10] sshd: listening on 0.0.0.0:40123",
"[2026-07-24 09:12:11] superheat-agent: instance is ready"
]
}
| Parameter | Value |
|---|---|
tail | how many of the most recent lines to return |
| Range | 1 to 1000 |
| Default | 200 |
A tail outside that range is rejected rather than clamped, so ask for 1000 if you want the maximum. There is no pagination and no way to reach further back than the last 1000 lines. See Instances for the rest of the endpoint's shape.
These are container logs
The lines you see are the container's own output — the agent's provisioning steps, and anything the workload writes to standard output or standard error. That is the whole scope.
They are not your application's log files. If your training script writes to /workspace/train.log, or a framework rotates files into a logs/ directory, none of that appears here. Read those over SSH:
tail -f /workspace/train.log
The base image keeps two of its own files on disk for the same reason, and they hold more detail than the container stream does:
| File | Contents |
|---|---|
/var/log/superheat/jupyter.log | the JupyterLab server's output |
/var/log/superheat/onstart.log | the output of the template's onstart script |
If you want your own process visible in the console view, have it print to standard output rather than only to a file.
What survives
Logs belong to the instance. A stop keeps them and adds a line recording that the container stopped and the disk was retained; a start continues the same stream. A destroyed instance drops out of the Instances list, so the console view is no longer reachable — read what you need before you destroy. See Stop vs destroy.