Understand AppLaunch service logs

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 textERROR 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. text404 means no matching resource; text401 or text403 means authentication or permission prevented access; text429 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 or 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 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 textWARN, textERROR, textSEVERE, exceptions, stack traces, or a named plugin/mod, then read upward to the first cause. See Use the Minecraft console.

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 textlast_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.