Skip to main content
The Logs tab streams live docker compose logs output from your VM into the dashboard. Open it, pick which install you want, watch.

​
What you see

  • Live stdout + stderr from the install’s containers.
  • Color-coded levels when the app emits them (info / warn / error).
  • Timestamps on each line.
  • A pause toggle if a chatty app is making the view unreadable.
  • Search/filter to grep through what’s on screen.

​
Picking an install

The selector at the top lists every install on this VM. Pick one — the view streams its logs. Switch selectors any time without leaving the page. There’s no “host logs” view; the host itself doesn’t run a single log stream that’s meaningful. Use journalctl from the Terminal tab if you need system-level logs.

​
Scrollback

The view holds the most recent ~10 000 lines. For older logs:
  • From the Terminal tab: docker compose -f /etc/suji/installs/<install-id>/compose.yaml logs --tail=10000 --since=24h <service>
  • Or journalctl --since=... if you want host-side context.
We don’t ship logs to a remote store by default. If you need centralised logging, install a log shipper as a sidecar (Vector, Promtail, etc.) and point it at your collector.

​
Common patterns

Logs tab → pick the install → scroll to the top of the most recent restart. The startup error (database connection refused, EACCES on a data path, missing env var) is almost always in the first 30 lines.
Open the install’s Logs. Trigger the webhook from the third-party service. If you don’t see any inbound activity, the request never reached the app — check the Cloudflare Tunnel and DNS for <install-subdomain>.suji.fr. If you see a 4xx/5xx, the app rejected it; the error body will tell you why.
Logs alone aren’t enough — pair them with the Metrics tab to see CPU/memory pressure at the same time as the slow events.

​
Next

Terminal

Run ad-hoc commands when the logs aren’t enough.

Network

Inspect the public IP, hostname, and traffic counters.