# Understand AppLaunch service logs

> Read timestamps, severity levels, requests, build output, container streams, and Minecraft console messages.

Logs record what a service or application reported. A log line is evidence, not automatically the root cause. Match its timestamp to the action you tested and start with the earliest relevant failure.

## Severity levels

PHP, WordPress, and some Docker entries can include a level:

- **CRITICAL** means the process reports a condition that can prevent an important operation or the application from continuing.
- **ERROR** means a request or operation failed.
- **WARNING** means something unexpected happened but the process may have continued.
- **NOTICE** means an unusual condition or noteworthy event that is not necessarily a failure.
- **INFO** records normal lifecycle or application events.
- **DEBUG** contains detailed diagnostic information and is usually useful only when tracing a specific problem.

Severity comes from the application or runtime. An `ERROR` line matters most when its time and request match the reported problem. A repeated warning can still indicate a real configuration issue, while an isolated warning may be harmless.

## PHP and WordPress logs

Open the site's **Logs** tab and choose:

- **Logs** for PHP or web-runtime messages. Each structured entry shows a timestamp, level, and message.
- **Access** for web requests. Entries can show timestamp, client IP, HTTP method, path, and response status.

Common HTTP status groups are:

- **2xx:** the web server completed the request successfully.
- **3xx:** the visitor was redirected. Repeating 3xx requests can indicate a redirect loop.
- **4xx:** the request was rejected or the resource was unavailable. `404` means no matching resource; `401` or `403` means authentication or permission prevented access; `429` means too many requests.
- **5xx:** the server or application failed while handling the request. Use the same timestamp and path to find the corresponding error entry.

The **Lines** control changes how many recent entries are loaded. **Live** streams new entries; **Live (fallback)** means the dashboard is polling because the WebSocket is unavailable. **Auto-scroll** follows the newest entry until you scroll away.

Use [PHP backups and logs](/php-mysql/backups-and-logs/) or [WordPress backups and logs](/wordpress/backups-and-logs/) for service-specific causes.

## Docker logs

Docker separates two sources:

- **Build Logs** show repository checkout, image pull, Dockerfile or Compose build, and deployment preparation. Use these when an app never reaches a running state.
- **Logs** show output emitted by running or recently exited containers. Use these when an app starts, crashes, rejects a request, or behaves incorrectly.

For multi-container apps, **All containers** combines streams and labels the container. Select one container to isolate it. Failed and exited containers remain selectable while the node can still see them. A message is whatever that container wrote to its output; its format and level are controlled by the application.

See [Read Docker logs](/docker/logs/) for a build-versus-runtime troubleshooting sequence.

## Minecraft console

Minecraft uses **Server → Console** instead of a separate Logs tab. It combines server runtime output, AppLaunch state messages, and commands sent from the dashboard. Colours distinguish command, state, and runtime sources; they are not a universal Minecraft severity scale.

Server families, plugins, and mods choose their own message format. Look for timestamps and terms such as `WARN`, `ERROR`, `SEVERE`, exceptions, stack traces, or a named plugin/mod, then read upward to the first cause. See [Use the Minecraft console](/minecraft/console-and-commands/).

## Portfolio information

Portfolio hosting is static and does not expose an application-runtime or shell log stream. Use editor validation errors, publish errors, domain status and `last_error`, browser developer tools, and contact-form submission statuses instead.

Contact-form status meanings include:

- **Saved:** the submission was received and stored.
- **Recipient not verified:** delivery remains queued until the recipient is verified.
- **Email delivered:** forwarding completed.
- **Email failed:** the submission may be stored, but email forwarding failed; read the displayed delivery error.

## What to include in support

Provide the service and site/app name, UTC timestamp, exact action, request path or container, first relevant error, and a small amount of surrounding context. Remove passwords, tokens, cookies, private keys, full IP lists, and personal customer data.