Logs

Logs are how you understand what your service is doing — what it printed during a build, what's happening in real time as it serves traffic, and what went wrong when something broke. Inhank Cloud captures everything your service writes to stdout and stderr and makes it searchable in the dashboard.

Two kinds of logs

Build logs

Build logs show every line written during a deployment's build phase:

• The detected runtime (Detected Node.js, etc.)
• Dependency installation
• Your build command output
• Packaging steps
• The final success / failure message

Build logs persist for 30 days after the deployment completes.

Following a live build

Click the row of a deployment that's currently Building. The log streams in real time, autoscrolling as new lines arrive. The page does not need to be refreshed.

Reading a completed build log

Click any past deployment's row. The full text is shown, with the final status (Live, Failed, Cancelled) at the top.

Exporting

Use the ⋯ menu in the log viewer to:

• Download the log as a plain .log file.
• Copy link to share a specific deployment's log with a teammate (anyone with access to the service can open the link).

Runtime logs

Runtime logs show what your service writes while it's actually running — HTTP request handlers, background workers, scheduled tasks, anything that prints.

Live tail

Open your service → Logs tab. By default you see the last few minutes with new lines streaming in.

• Pause by scrolling up; a Resume button appears at the top.
• Resume to jump back to live tail.

The connection auto-reconnects if your network drops.

Time range

Pick a window from the time-range selector:

Search

The search box does substring match on lines in the current window.

ERROR                # all lines containing ERROR (case-insensitive)
"timeout in 5s"      # quoted exact phrase
user_id=abc123       # find lines with this token

Structured logs

If your application logs JSON, the dashboard auto-detects it. Each line can be expanded to show fields as a clean table. Works out of the box with common libraries — pino, winston, bunyan (Node.js), structlog, loguru (Python), zap, slog (Go).

You don't have to use JSON, but it makes logs easier to search and filter.

Exporting

The same ⋯ menu offers:

• Download .txt — flat text, one line per event, up to 10,000 lines.
• Download .jsonl — JSON Lines with timestamps, useful for piping into your own tools.

Retention

After retention, the logs are deleted server-side. Build logs older than 30 days will show a "log expired" placeholder; runtime logs simply roll off the visible window.

If you need longer retention, contact support.

Debugging with logs

A few patterns that turn logs into a powerful debugger.

"My app crashed — what was the last thing it did?"

1. Open the Logs tab.
2. Set the time range to the last 5 minutes (or whenever the crash was).
3. Scroll to the bottom. The last lines before the gap are what your app was doing when it died.

"Requests are failing intermittently"

1. Add a unique correlation ID at the start of each request (or use your framework's built-in request ID).
2. Log the ID alongside every meaningful event for that request.
3. Search runtime logs by the failing request's ID to see the full path.

"My build worked yesterday and fails today"

1. Open yesterday's successful deployment's build log.
2. Open today's failing deployment's build log.
3. Compare the dependency-install sections — a fresh npm install may have resolved a different version of a transitive dependency.

"I see no logs at all"

• Has the deployment actually finished? Logs only appear after the build completes the cloning phase.
• Is your service actually running? 0/0 instances (in Resource Usage) means nothing is producing logs.
• Is your app silent? Add a startup log line (console.log('booted'), print('booted')) and redeploy to confirm logs are reaching the dashboard.
• Is your time range correct? Switch to Last 1 hour to widen it.

Limits

• Search returns up to 10,000 matching lines per query. Narrow the time range or query if you hit this.
• Live tail throttles around 1,000 lines/second per service. Lines past this are batched.
• Lines longer than 16 KiB are truncated with a …[truncated] suffix.

Best practices

• Log to stdout/stderr only. Writing to files inside the container loses data on restart and doesn't reach the dashboard.
• Use structured (JSON) logs for anything beyond toy apps. They search and filter much better than plain text.
• Don't log secrets. Inhank Cloud masks known env-var values from build logs, but defense-in-depth is your responsibility for runtime.
• One event per line. Multi-line tracebacks are hard to search. Either collapse to one line, or include the stack in a JSON field.
• Include enough context. Request IDs, user IDs, and timestamps make logs useful weeks later.

Related