Logs & Monitoring

Vessl gives you real-time visibility into your application's output directly from the dashboard — no SSH access required.

Deploy logs

Every deployment has a live log stream. To view it:

1. Open your application and go to the Deployments tab.
2. Click on any deployment to open the deployment drawer.
3. The build and deploy log streams automatically in real time while the deployment is in progress.

The log is split into phases:

Phase	What you see
Clone	Git clone progress, commit SHA
Build	Nixpacks or Docker build output, layer cache hits
Release	Container start, post-deploy command output
Health check	Health probe results (pass / fail), HTTP status codes

If a deployment fails, the drawer shows exactly which phase failed and the last lines of output before the error. Your previous version keeps serving traffic until the new one is healthy.

Application logs (runtime)

To view your running app's stdout/stderr output:

1. Open your application.
2. Go to the Logs tab.

The logs tab streams your container's live output. This includes anything your app writes to stdout or stderr — framework log lines, errors, print statements, etc.

Write to stdout

Vessl captures logs from the container's stdout/stderr stream. Make sure your app (and your logging library) writes to stdout, not just to a file. Most frameworks do this by default in production mode.

For Laravel: LOG_CHANNEL=stderr in your env vars routes Laravel's log to stderr, which Vessl captures. For Django: Django's default logger writes to stderr when DEBUG=False. For Node.js: console.log and console.error go to stdout/stderr automatically.

Daemon / worker logs

Background workers (daemons) have their own log stream. To view:

1. Open the Overview tab.
2. Find the daemon card and click View Logs.

Each daemon runs in a separate container, so its logs are independent from the main web process.

Add-on logs

Database and Redis add-on containers have their own logs too. Navigate to the Services page in your project, click the service (e.g. your PostgreSQL instance), and open its Logs tab.

Health checks

Vessl performs an HTTP health check against your app before swapping traffic to a new version. By default it checks GET / and expects a 2xx or 3xx response. You can customise the path in Settings → Health Check Path.

If the health check fails:

• The canary container is stopped.
• Your previous version keeps serving.
• The deployment is marked Failed.
• The deployment drawer shows the HTTP status code and response body from the health check.

A common pattern is to expose a dedicated /health or /up endpoint that returns 200 OK quickly without hitting the database. Set Health Check Path to /health in your app settings.

Uptime monitoring

Vessl monitors the platform itself, not your individual application uptime. For per-app uptime monitoring, use an external service like UptimeRobot or BetterStack pointed at your app's public URL or /health endpoint.

Common log patterns

App crashing on startup (exit code 1) The post-deploy command ran but the container exited immediately after. Look for stack traces in the deploy logs — usually a missing environment variable, a failed database connection, or a syntax error.

Health check returns 502 The container started but isn't listening on the expected port. Confirm your app reads process.env.PORT (Node.js) / $PORT (other runtimes) and binds to 0.0.0.0.

Build log cut off / "context deadline exceeded" Very long builds (image pulls + compile steps) can time out. Try again — cached layers make subsequent builds much faster. If the problem persists, check if your Dockerfile or build command is pulling large dependencies on every build.

"No such container" in logs tab The app has no running replica — it may be stopped or failed. Check the Overview tab for the current status and trigger a deploy or start from there.