A hosting slot, a completed build, a running process and a working Discord command are separate checkpoints. Start with the status shown in your bot panel and Console. Repeatedly pressing Start can replace an in-flight build; it does not make a queue move faster.
For your own-code bot, check the entry file and dependency manifest before starting. Managed Marketplace bots use the reviewed release and supported configuration controls from their listing; do not try to repair them by replacing their source files.
Follow the current stage
| What you see | What it means | Next action |
|---|---|---|
| Setting up or installing | The runtime is being prepared | Wait; open bot status if Files is not available yet |
| Queued or waiting for the builder | Build capacity has not been assigned yet | Leave the request in place and watch Console |
| Installing packages or compiling | Dependencies or a runnable artifact are being prepared | Read build output; a first build can take longer than a cached start |
| Build failed | Dependency installation, compilation or output validation failed | Fix the first relevant error, then retry Start |
| Build complete but bot offline | Preparation finished, but launching or connecting still needs attention | Check runtime errors, token, entry path and permissions |
| Online but silent | A process is running, but a feature may be misconfigured | Test a command and follow the interaction handler's logs |
The display may update after the underlying action. Check the latest Console output before sending another Start or Stop.
Build memory and runtime memory
Supported own-code projects use shared build workers to prepare dependencies and compiled output outside the bot process's runtime memory budget. Your plan still limits the running bot to its allocated RAM, CPU and disk. A successful build does not show that the application will fit in 256 MB at runtime.
Build capacity is finite. A busy queue, builder timeout or builder out-of-memory error concerns preparation. A running bot that is killed near its memory limit needs runtime investigation. Use out-of-memory troubleshooting and measuring bot memory, rather than treating every memory error as a reason to change plans.
Check the project layout
For Node, include package.json and the matching lockfile. The shared build can install build dependencies and run a build script; production dependencies must be under dependencies because development-only packages are pruned before runtime. Point MAIN_FILE to the resulting JavaScript file, such as dist/index.js, for a TypeScript project.
For Python, include requirements.txt and your local modules. A missing local folder is not fixed by adding an unrelated package from a public package index. Keep the start file's relative path consistent with the uploaded or Git project layout.
For Java, JAR_FILE must name the runnable jar produced by the project. If uploading a prebuilt jar, include its dependencies in a shaded or fat jar. For source builds, include the build files and wrapper files your project uses and confirm where the output is written.
For Go or Rust, a prebuilt binary must be compatible with the Linux runtime and its architecture. A binary compiled for another operating system will not become compatible just because it was uploaded.
Recover without losing useful files
- Read the first failing build step and identify whether it concerns source access, a dependency, compilation, storage or output.
- For Git failures, check the repository and branch in Deploy. Free supports public repositories; private credentials require a paid plan.
- For disk failures, review archives, dependencies and old output before deleting anything. Keep database and user-data backups separately.
- If interrupted or cancelled, check for a newer pending Start and verify your settings before retrying once. Stop, runtime changes and replacement workflows can invalidate old build work.
- After a successful build, inspect the runtime log and test a real Discord command. Do not stop at a green build result.
A completed compatible build may be reused on a later start. Changes to code, dependencies or the runtime can require fresh work; caching is not a promise of an instant start. If a retry keeps failing, share the error category, runtime and relevant sanitized lines through support. Never send tokens, private repository credentials or a full environment dump.
Still stuck? Contact support