Support

Troubleshoot Node.js Hosting

View as Markdown

Diagnose and resolve common errors when deploying and operating Node.js apps on GoDaddy's hosting platform.

Overview

This page covers common failures when using the Hosting API, with causes and steps to resolve them. Go to Read logs for build and application output when diagnosing runtime failures.

App creation job stuck in pending

Symptom: GET /app-operations/{operationId} returns status: "PENDING" for more than two minutes.

Cause: Upstream provisioning delay or a transient platform error.

Resolution:

  • Wait two minutes. Most create jobs complete within 30–60 seconds.
  • If still pending after 2 minutes, treat the job as failed.
  • Retry POST /apps with a new app name. Don't reuse the stuck operation id.

Source import job failed

Symptom: GET /apps/{appId}/imports/{importId} returns status: "FAILED".

Cause: A malformed zip or build failure causes most import failures.

Resolution:

  • Confirm the zip root contains a package.json. The build system must find it at the top level.
  • Confirm the zip doesn't contain a nested project root (e.g., a folder wrapping all the files).
  • Verify the app meets all deployment requirements. Go to Node.js app requirements for the full list.
  • After fixing the zip, upload again with POST /apps/{appId}/imports.

401 Unauthorized

Symptom: Any request returns 401 Unauthorized.

Cause: The token is expired, revoked, or missing a required scope.

Resolution:

  1. Check the token expiry date in the Personal Access Tokens portal.
  2. Verify the token includes the scope the operation requires. Go to Hosting core concepts for the full scopes table.
  3. Note: GET /apps/{appId}/secrets requires hosting.secret:read.
  4. Create a new token with the correct scopes if the original has expired or lacked a scope.

429 Too Many Requests

Symptom: Requests return 429 Too Many Requests.

Cause: Rate limit exceeded. Limits are enforced per client IP and vary by operation (10–120 req/min).

Resolution:

  • Implement exponential backoff. Start with a 1-second delay and double on each retry, up to a maximum of 30 seconds.
  • Avoid tight polling loops — use 2–5 second intervals when polling job status.
  • Go to Rate limits for general guidance.

App not running after publish

Symptom: GET /apps/{appId}/status shows the publish variant in a non-running state after POST /apps/{appId}/deployments.

Cause: The app might have a startup error, or the deployment is still rolling out.

Resolution:

  1. Allow up to 30 seconds for the status to flip to running after a publish. Poll with a five second interval.

  2. If the status remains non-running, fetch application logs to check for startup errors.

  3. Fix the error, upload a corrected zip, and publish again. Go to Deploy your Node.js app for the full deploy flow.

  4. Fetch application logs:

    curl -s "$BASE_URL/v1/hosting/apps/$APP_ID/logs?variant=PUBLISH" \
      -H "Authorization: Bearer $GODADDY_PAT" | jq .

Agent & Automation Notes

Scopeshosting.application:read, hosting.log:read
Rate limit60 req/min per credential
IdempotentYes
DestructiveNo
On failureAll diagnostic calls on this page are read-only and safe to retry.

Last updated on

How is this guide?

On this page