Skip to main content

Overview

Logs are your window into what’s happening inside your services. Ardor captures everything — from build output to runtime errors — so you can debug issues and monitor performance.
Cerebrum reads logs for you. Just say “why is my app crashing?” or “check the build logs” — Cerebrum will analyze logs and explain what’s wrong. The details below help you understand logs yourself.
Service Logs Interface

Log Types

Ardor provides two types of logs for each service:

Build Logs

Docker build output — dependency installation, compilation, image creation

Runtime Logs

Production output — your app’s stdout/stderr while running in deployment

Build Logs

Build logs show everything that happens during docker build:
  • Base image download
  • Dependency installation (npm install, pip install, etc.)
  • Code compilation
  • Asset bundling
  • Any commands in your Dockerfile

What to Look For

Common Build Errors

Fix: Check package name spelling, version availability, or if it’s in a private registry.
Fix: Check Dockerfile syntax. Common issues: typos, missing backslashes in multi-line commands.
Fix: The file doesn’t exist or isn’t committed to git. Check the path and make sure it’s not in .gitignore.
Fix: Build needs more memory. Try smaller base images or contact support for larger build instances.

Runtime Logs

Runtime logs capture your app’s output while it’s running in production:
  • stdout — normal output, print statements, info logs
  • stderr — errors, warnings, exceptions
  • Framework logs — web server access logs, database queries, etc.

Reading Runtime Logs

Adding Useful Logs

Help yourself debug by adding structured logging:
Use structured logging (JSON format) for easier searching and filtering. Include context like user IDs, request IDs, and timestamps.

How Logging Works

Zero configuration required. Ardor automatically captures everything your app writes to stdout and stderr. Just use print(), console.log(), or your favorite logging library — it all shows up in the logs.

Debugging with Logs

Startup Issues

App won’t start? Check logs in this order:
  1. Build logs — did the image build successfully?
  2. Runtime logs — is the app crashing on startup?
  3. Look for: missing env vars, connection errors, port conflicts

Request Failures

API returning errors? Look for:
  • Stack traces with line numbers
  • Database query errors
  • External API failures
  • Timeout messages

Performance Issues

App slow? Look for:
  • Long-running queries logged with duration
  • Memory warnings
  • Connection pool exhaustion
  • Rate limiting messages

Log Best Practices

  • ERROR — something broke, needs attention
  • WARN — something unusual, might be a problem
  • INFO — normal operations, useful for tracking flow
  • DEBUG — detailed info for debugging (usually disabled in production)
Bad: "Error processing request"Good: "Error processing request user_id=123 endpoint=/api/orders error=ConnectionTimeout"
Never log passwords, API keys, or tokens. Mask sensitive data in your logging code.
Generate a unique ID for each request and include it in all logs. Makes it easy to trace a request through your system.

Troubleshooting

Cause: App isn’t writing to stdout/stderr, or container isn’t running.Solution:
  • Make sure your app logs to stdout, not to files
  • Check if the container is actually running (deployment status)
  • Verify your logging library is configured correctly
Cause: Very high log volume or app crashed before flushing.Solution:
  • Reduce log verbosity in production
  • Flush logs explicitly before app exit
  • Check for app crashes in earlier logs
Cause: Too many logs, error buried.Solution:
  • Use search/filter to narrow down
  • Filter by time when the error occurred
  • Search for keywords from the error message

What’s Next

Deployments

Understand the build and deploy process

Development Container

Test and debug in your dev environment

Variables & Secrets

Configure your app with environment variables

Build with Cerebrum

Let Cerebrum help you debug issues from logs