Logs

Logs are where you spend time when something's gone wrong, so Appentic collects them automatically and streams them to the dashboard in real time. There's nothing to configure on the service side: anything you write to stdout or stderr is captured. For most languages that means console.log, print, log.Println, or your structured logger of choice is all you need.

Viewing logs

Open your service and click Logs. By default you'll see runtime logs from the currently running revision. Three tabs sit at the top:

• Runtime. stdout and stderr from your running service. This is what you look at when investigating production behavior.
• Build. Output from the most recent build. Useful when a deploy just failed and you want to see why.
• Deploy. Platform-level events: health checks passing or failing, traffic swaps between revisions, and automatic rollbacks.

Streaming vs history

The logs panel streams new lines as they're emitted, so you can tail a running service the way you'd tail a file locally. Appentic also retains log history per the plan applied to your workspace, so you can scroll backwards with the Time range selector when the event you care about happened an hour ago.

Filtering

Filter by severity (info, warn, error) or search for a substring. Filters apply to both the live stream and the history view, so you can tail only 5xx responses, or only lines mentioning a specific user ID, without losing the stream.

Structured logs

If your service emits logs as JSON on stdout, Appentic parses them and lets you filter by any top-level field. This is the recommended format for production workloads because it turns free-text logs into queryable events.

A typical JSON log line from a web service:

{"level":"info","msg":"request","method":"GET","path":"/api/users","status":200,"duration_ms":42,"user_id":"u_1234"}

With that shape you can filter on user_id=u_1234 to pull every log line for a specific user, or on status>=500 duration_ms>1000 to find slow errors, without grepping free text.

Logs from metrics

A common debugging flow: an alert fires on an error-rate spike, you note the time range, and you switch straight to logs with the same time range selected. The metrics and logs tabs share their time selector specifically so you don't have to retype timestamps while you're trying to figure out what broke.