Troubleshooting

Before debugging code, check whether the platform is healthy. The status page carries live uptime for every AletCloud service, along with any open incident or scheduled maintenance.

The status page runs outside the AletCloud datacenter, on separate infrastructure in another country. That is deliberate: a status page hosted next to the thing it monitors goes dark exactly when it is needed most. This one keeps reporting through a full datacenter outage.

• Subscribe to be emailed the moment an incident is opened or resolved, rather than finding out by going looking.
• Incidents and maintenance are published as RSS at status.aletcloud.com/rss.xml.
• If the service in question is green and the problem persists, the symptoms below are the fastest route.

Find the one that matches what is happening.

The build succeeded but the app never comes up

Almost always the port. The app is either bound to localhost instead of 0.0.0.0, or listening on a different port from the one traffic is routed to.

• Read the runtime logs. An app that logs it is listening on 127.0.0.1 or localhost has found its own problem.
• Make the server read the PORT environment variable instead of a hardcoded number.
• If the app must use a fixed port, set that port in the app’s settings so traffic is routed to it.
• Confirm a development server is not being used as the production command.

The build failed

Open the deployment’s build log, which shows the exact step and error. The usual causes are a dependency that installs locally but not in a clean environment, a build script expecting an environment variable that was never set, or a lockfile out of sync with package.json.

• Environment variables are available during the build, so add whatever the build needs and redeploy.
• Commit the lockfile. A build from a clean checkout cannot reuse what only exists on a laptop.
• If it builds locally but not here, build from a fresh clone on the same machine. That usually reproduces it.

The app starts, then restarts over and over

The process is exiting or hanging after start. Runtime logs show why, usually an unhandled exception on startup, a missing environment variable, or a database connection that fails and takes the process down with it.

It is not an impatient health check. Liveness does not run at all for the first sixty seconds, and it only restarts a container that has stopped responding entirely.

The app ran out of memory

This is detected specifically and reported as such, rather than leaving a container that just keeps dying. The app needs more memory than its plan allows. Either move to a plan with more memory and redeploy, or reduce what the app holds in memory at startup.

Build steps count too. Some frontend builds are far hungrier than the app they produce, so a build that dies here may need a bigger plan only while it builds.

The first request after a while is slow

Expected on the free Solo plan. A free app sleeps after a spell without traffic and wakes on the next request, so that request pays the startup cost. A paid plan keeps the app always on.

A custom domain is not verifying

• Check the TXT record name and value match exactly what the console shows, the _alet-challenge prefix included.
• Some DNS providers append the domain to whatever is typed in the host field. If the result reads _alet-challenge.yourdomain.com.yourdomain.com, enter just the prefix instead.
• Give it time. DNS changes usually spread within an hour, and unverified domains are re-checked every ten minutes.
• The traffic record only appears after ownership is proven. If there is no address to point at, step one is not finished.

A worker has no URL

That is correct. A background worker has no public route and no path prefix by design, because there is no HTTP server to expose. If it was meant to serve traffic, change the service type to a web service and redeploy.

Django returns 400 for every request

ALLOWED_HOSTS does not include the domain being visited. Add the app’s aletcloud subdomain and any custom domain, then redeploy.

The site is live but showing an old version

Check the deployment history to confirm which build is actually live. If the newest build is the live one, the old copy is being held by a browser or by a CDN in front of the site. Hard refresh, and purge the cache at the CDN if there is one.

Have the app name and the build or runtime log to hand, since most questions are answerable from the log alone. Support is free, for getting something working as much as for fixing what broke.