Documentation · Deployments
Reading deployment logs.
Deployment logs show what happened when Host Luma prepared and published a connected GitHub project. Use them to identify the first failed stage, make one focused correction in GitHub, and publish again through the same workflow.
Start here
Logs are a record of a deployment attempt, not a diagnosis by themselves.
Host Luma AI Hosting publishes supported static website output from a connected GitHub project. A deployment log records the hosting-side stages used for that attempt: repository checks, clone, the supported build path when needed, static publish, and preview validation where it applies. The deployment status tells you whether the required path completed; the log gives the context behind that result.
Logs are most useful when you treat them as a sequence. Find the first meaningful failure, then check whether the same project build works locally. Correct the code or configuration in GitHub, commit the focused change, and use the established connected workflow for the next deployment. Do not create a manual-upload path to work around a failure: it makes it harder to know which source produced the public result.
This guide is for the public static workflow. A project that needs a long-running Node server, PHP runtime, database, Docker container, server-side rendering, custom API runtime or background worker is not fixed by a different log setting. It needs a platform that explicitly provides those services.
How to access logs
Start from the relevant AI Hosting project in the Portal.
Open the project
Sign in to the Host Luma Portal and open the AI Hosting project you are investigating. The Portal is the customer-facing record for project and deployment state.
Find the deployment result
Review deployment status, history and build information for the relevant attempt. Compare its timing with the GitHub change you expected to publish.
Read in order
Begin at the start of the latest failed attempt and locate the first relevant error. Later lines often report the consequence of that earlier failure.
Avoid sharing deploy keys, tokens, passwords or other credentials when asking for help. A useful support request contains the project name, deployment time, repository context, status and a relevant non-sensitive log excerpt.
Typical lifecycle
Read the log as a pipeline.
Mermaid workflow source
flowchart TD
A[Repository] --> B[Clone]
B --> C[Dependencies]
C --> D[Build]
D --> E[Publish]
E --> F[Preview]
F --> G[Deployment Complete]Common log sections
What each stage is trying to prove.
Repository and clone
The workflow begins by validating the connected repository and resolving the source it is allowed to use. It then clones the expected branch and checks that the cloned commit matches the validated source. This protects the publishing path from a mismatched or stale queue value.
If this is where the deployment stops, check the repository selection first. For a private repository, the per-application deploy-key access must be configured and verified. For an organisation-owned repository, access needs assessment and authorisation; it is not an unconditional self-service promise.
git clone failed
git clone timed out after … seconds
These messages are not instructions to retry indefinitely. Confirm that the correct repository is connected, that it still exists and is readable with the configured access, and that the intended branch and source are available.
Dependencies and install
Supported frontend projects use the npm-based build path. When a project needs a build, the deployment can install its declared dependencies before running the configured build command. Static HTML does not need this stage.
Package-manager output can include notices, deprecation notices or audit information. Those messages can be useful to the project owner, but they do not necessarily explain a failed deployment. Look for the command result and the first dependency error that causes the install to stop.
Dependency install failed for framework astro
Typical causes are an invalid or incompatible dependency declaration, a missing package, a broken lockfile, or a project that only works with a package manager not presented as a supported public build contract. Reproduce the normal production build locally with npm, correct the project and commit the fix.
Build and compile
For a supported framework, the build stage runs the project’s normal production build. Tools may describe that work as bundling, compiling, generating or exporting. Host Luma does not promise a separate server runtime after this point: the purpose is to create static files for publishing.
A build warning can be real without being fatal. For example, a tool may warn about bundle size or a deprecated package while still completing with a usable static output. A build error is relevant when the build command returns a non-zero result or the deployment status is failed.
Build failed for framework next-static
Check the first framework error above this summary. Syntax errors, unresolved imports, missing environment values used at build time, and configuration errors need to be fixed in the repository. A local production build is the fastest confirmation that the correction is real.
Output detection
A successful build still needs to produce usable static output. The workflow identifies the expected output directory for the supported project type, then checks that the directory exists and contains files. Common patterns are dist for Vite or Astro, build for Create React App-style output, and out for a Next.js static export.
Those names are common conventions, not a substitute for your configuration. If the project changes its output directory, it must still produce the static result expected by the publishing workflow.
Build output directory not found after build: dist
Build output directory is empty: out
These messages usually point to the wrong project type, a missing static export, a changed build configuration, or a build that wrote files somewhere other than the expected output. Do not copy source files into an output folder just to bypass the check; correct the production build.
Publish
After the static output is ready, Host Luma publishes that output to the project’s public site location. The publish stage is intentionally after the build. A build failure does not replace the last published static result with a partial build.
A publish failure is less commonly a code problem than a build failure, but it still needs the status and surrounding context. Capture the deployment time and project name, then contact support with the non-sensitive log context. Do not try to write to server paths or use manual uploads as a substitute for the managed route.
Preview validation and completion
For a project with a preview address, the deployment can validate the expected HTTPS preview response. A successful result records the completed deployment, along with the build information and history used by the Portal.
A preview check can be temporarily pending while HTTPS or routing converges. That is different from a project compile failure. Read the status and attempt details before changing code. Customer custom domains and CDN delivery are planned product work; a working hostluma.app preview URL should not be described as a custom-domain launch.
SUCCESS … commit=…
Open the preview URL once the result is successful. Confirm the expected homepage, primary navigation, assets and browser-side integrations before you share it with a client.
Successful results, warnings and exit codes
Not every noisy log needs a code change.
A successful deployment usually has a simple story: the connected repository was accepted and cloned, any required npm dependencies installed, the supported project build generated static output, that output was published, and preview validation completed where applicable. The Portal’s deployment status is the customer-facing result; the log explains the work behind it.
It is normal for build tools to print information that looks serious at first glance. npm may print audit or deprecation notices. A frontend compiler may report a large bundle, an unused import, or a recommendation about a future configuration change. These can be worth fixing in the repository, but they do not automatically explain a failed deployment. If the build stage completed and the deployment status is successful, treat the message as maintenance work rather than an incident.
Conversely, do not dismiss a line merely because it is not in red in your editor. A message is operationally important when it stops the required command, prevents static output being found, prevents publishing, or is followed by a failed deployment status. Start with the first such point in the attempt rather than searching the whole log for the word “warning”.
What a successful record tells you
The hosting-side pipeline reached a publishable static result. You should still open the preview URL and verify your pages, assets and browser-side integrations.
What a warning tells you
A tool has something to report, but it may not have blocked the build. Record it, decide whether it belongs in normal project maintenance, and avoid changing deployment configuration without a failure.
What an exit code tells you
The associated command did not complete successfully. The next question is which stage failed and what the first specific error says—not which number should be retried.
Build failed for framework vite, work upward to the first Vite error and fix that source problem before publishing again.Use the right evidence
What logs can and cannot tell you.
Hosting-side deployment stages
Whether the connected source was processed, the build ran, static output was detected, publishing completed, and preview validation progressed.
Every user journey
A completed deployment does not prove that your content is correct, a third-party booking service is configured, or every browser and device experience meets your requirements.
Secrets or credentials
Do not add passwords, access tokens, private keys or confidential data to project output or support excerpts. Use safe project context instead.
For example, a static chatbot interface can build and publish successfully while its external service returns an application-level error. The deployment log can tell you that the static interface reached the preview URL; it cannot turn Host Luma into that chatbot’s API host or database. Apply the same distinction to forms, analytics, booking platforms and other browser-side integrations.
Use the preview URL after a successful result. Check the homepage, important internal links, assets, page titles and relevant external journeys. That final review is where you confirm the published static site is the version you meant to share.
Common errors
Use the message to choose the next check.
| Example message | What it means | Likely cause | Recommended action |
|---|---|---|---|
Repository validation failed | The connected source could not be accepted for deployment. | Wrong repository, changed repository state or access configuration problem. | Confirm the project connection and repository context; use support for connection or access changes. |
git clone failed | The expected source could not be cloned. | Repository is unavailable or the configured access cannot read it. | Check the repository and private-repository deploy-key setup. Do not expose access credentials in a log request. |
Dependency install failed | The npm dependency stage stopped. | Invalid dependency declaration, missing package, incompatible lockfile or unsupported package-manager assumption. | Run the normal npm production build locally; repair the project files and commit the correction. |
Build failed for framework … | The project’s production build did not complete. | Syntax, import, configuration or build-time-value problem. | Read the first framework error, fix it in GitHub and publish the next change. |
Build output directory not found after build | The build did not create usable static output where expected. | Wrong output configuration, failed static export or the wrong repository root. | Confirm the framework’s static-output configuration and test the build locally. |
Build output directory is empty | The expected output folder exists but has no publishable files. | Build configuration did not generate a finished site. | Check the build command and output directory; do not publish development source as a workaround. |
Static publish failed | The static result could not be published after a successful prior stage. | Hosting-side publish issue or an invalid publishable result. | Keep the project unchanged, note the deployment time, and contact support with the relevant non-sensitive excerpt. |
The exact surrounding output can vary by framework and project. The examples show the customer-relevant failure category, not a promise that every tool emits identical wording.
Troubleshooting workflow
Make one clear correction at a time.
- Identify the deployment attempt. Match the Portal result with the GitHub change you expected to publish.
- Find the first meaningful failure. Ignore later generic failure lines until you understand the first repository, install, build, output or publish error.
- Check project fit. Confirm that the project is static output, not an application requiring a long-running runtime.
- Reproduce the production build locally. Use the normal npm build for a supported framework and inspect the resulting static folder.
- Correct the source in GitHub. Commit a focused fix with a useful message, rather than changing dependencies, output paths and repository settings at once.
- Publish through the connected workflow. Review the next status and log as a new attempt. Keep the commit and result together in your release note.
- Escalate safely when needed. For hosting-side status, access, preview URL or publish problems, contact support with context but never secrets.
0 means the command completed successfully and a non-zero result means it did not. The useful question is which command failed and why, not whether a non-zero number should be manually retried.Quick troubleshooting table
Match the symptom to the next action.
| Problem | Possible cause | Recommended action |
|---|---|---|
| Deployment stops before build | Repository validation, clone or access issue. | Confirm the selected repository and access configuration; ask support to review a changed private or organisation connection. |
| npm install stops | Dependencies or lockfile are not usable for the project. | Run the normal npm production build locally, correct the project and commit the fix. |
| Build runs but produces no site | Wrong output folder or static export was not configured. | Check the framework’s static build output and read Supported Frameworks. |
| Build passes but preview looks wrong | Asset paths, client-side values or third-party browser integration need attention. | Open the preview URL, inspect the published result and correct the source; do not assume a successful build validates every external service. |
| Preview check is pending | Preview routing or HTTPS is still converging. | Read the deployment status before changing code. If it does not resolve, contact support with the deployment time. |
| The project needs a server or database | The project is outside static-hosting scope. | Assess a platform that provides the required runtime and services instead of forcing the project through a static build. |
Developer FAQ
Questions developers ask about a failed deployment.
Why did my deployment fail?
A deployment can fail during repository validation, clone, dependency installation, build, output validation, publish or preview validation. Start with the first relevant error, reproduce the normal project build locally where appropriate, correct the source in GitHub and publish through the same route.
Why does the build stop?
For a supported framework, the build stops when the normal project command cannot complete or does not produce valid static output. Read the first framework, dependency or output error—not only the final summary—and fix the project configuration or code.
Can I redeploy or rebuild?
The normal re-publish route is to correct or update the project in GitHub and publish the next change through the connected workflow. Separate customer-facing manual redeploy and rebuild controls are not part of this public product promise.
Where do deployment logs come from?
They record the hosting-side work done for a connected project, including repository checks, clone, supported build stages, static publish and preview validation where applicable.
Why are warnings different from errors?
Warnings can be emitted by a package manager or build tool while a build still completes. An error is relevant when it prevents a required stage from succeeding or the Portal reports the deployment as failed.
Can I use a private repository?
Private repositories can be configured through a per-application deploy-key flow. Access must be configured and verified for that application; do not assume a private repository will publish without it.
Can I reconnect GitHub myself?
Do not assume a self-service reconnect control. If a connection needs to change, contact support so the application access and deployment configuration can be reviewed safely.
Related documentation
Use logs alongside the project guide and compatibility reference.
Logs answer what happened in a specific attempt. For how to prepare and publish a project, read Deploy Your First GitHub Project. For framework fit and static-output requirements, use Supported Frameworks. For the overall product scope, read AI App Hosting and GitHub Website Hosting.
For current planned work, consult the Roadmap. For the current purchase route, see Pricing. For hosting-side help, use Support. This page does not describe roadmap features as live functionality.
Author: Host Luma editorial team. Technical review: Host Luma hosting team. Revision history: Version 1, 1 August 2026 — initial deployment-log reference.