Troubleshoot
Start here if something looks wrong. Match your symptom to a row below, walk through the first-aid steps, and follow the link to the page that explains the underlying behavior.
If your symptom isn't here — or first-aid didn't fix it — the escalation paths at the bottom of this page route you to the right place.
Find your symptom
| Symptom | First-aid | Go deeper |
|---|---|---|
| Build fails. Image won't build, deploy never starts. | 1. Build locally with the same Dockerfile + commands. 2. Check the Build logs tab on the failed deployment. 3. Confirm the build command, run command, and service port match your project. The running service is unaffected — old version keeps serving. | Reliability → Rollback |
| Service crashes on startup. Build passes; spherelet exits immediately. | 1. Check Runtime logs for the crash trace. 2. Confirm required env vars are set in the environment. 3. Test the image locally with the same env. | Environment variables |
| Rollout stuck — new version never goes live. | The new spherelet is failing its health check. Old spherelets keep serving. Check Runtime logs for the new version and confirm the health-check endpoint returns 200 only when actually ready. | Health checks |
| 5xx errors after a deploy. | 1. Watch Runtime logs for the error pattern. 2. Roll back to the previous deployment from the Deployments tab if the issue is post-deploy. 3. Check status.computesphere.com — sometimes it's the platform, not your code. | Service actions |
| Service shows running but every request returns 502 / connection refused. | Almost always host binding: your app is listening on 127.0.0.1/localhost instead of 0.0.0.0, so it's unreachable even though the spherelet is healthy. Bind your server to 0.0.0.0 on the configured port and redeploy. Use Runtime logs to confirm the address your app reports binding to. | Web service → Networking |
| Custom domain doesn't resolve. | 1. Wait — DNS changes take time to propagate (up to ~30 minutes typically, occasionally longer). 2. Flush your local DNS cache. 3. Confirm the DNS record matches the value shown in the console's domain status panel. | Custom domains |
| TLS certificate isn't issuing. | Certificate issuance requires the DNS record to resolve to ComputeSphere first. Confirm DNS resolution before opening a ticket. Issuance typically completes within minutes of valid DNS. | Custom domains |
| "Out of capacity" or "No spherelets available." | Your account has hit its spherelet capacity for the current tier. Either retire an unused service or upgrade. The account capacity is shown in Settings → Resources. | Spherelets |
| API token returns 401 / 403. | 1. Confirm the token hasn't been revoked in Settings → User tokens. 2. Confirm the token's scope (user / account / project) covers the resource you're touching. 3. If your user belongs to multiple accounts, send the x-account-id header to disambiguate. | API keys |
| I can't see a team I was invited to. | Switch accounts from the account picker in the top navigation (left of the notification bell). Each team invitation is scoped to one account. | Roles & access |
| Logs are blank on a running service. | 1. Confirm the service is actually receiving traffic — a quiet service is the most common cause of "no logs". 2. Some platform-side log lag is expected during incidents — check the status page. | Logs |
| Service URL changed unexpectedly. | It shouldn't. Auto-generated URLs only change when you delete and recreate a service. If you've added a custom domain, traffic continues to work on both. | Custom domains |
When to suspect the platform
| Signal | What to do |
|---|---|
| The status page shows an active incident on a surface you depend on | Subscribe to the incident for live updates. Your service may recover automatically once the incident resolves. |
| Multiple services in your account misbehave at once | Likely platform-side. Open a ticket — that's the signal the platform team uses to escalate. |
| 5xx rates surge across services that share nothing | Same as above — bundle the affected service names and timestamps into one ticket. |
| Status page is green, only your service is affected | Likely service-specific. Walk the symptom table above; if you still need help, ticket with logs and a timestamp. |
Escalation paths
| Channel | Best for |
|---|---|
| status.computesphere.com | Check before anything else. Many "is my service down?" moments are platform events you'll see on the dashboard. |
| support.computesphere.com | Service-specific issues, account questions, configuration help. Team and Enterprise customers get priority response. |
| support@computesphere.com | Email is fine for non-urgent questions. A ticket is faster to track and triage. |
| security@computesphere.com | Suspected vulnerabilities or security incidents. First acknowledgment within one business day — see Security. |
| billing@computesphere.com | Invoices, plan changes, SLA credit claims. See SLA → Filing a credit claim. |
When you ticket, what speeds up triage:
- Service name and environment — the platform team needs both to find the right resource.
- A timestamp — when did the symptom start? Window down to the minute if you can.
- The error message verbatim — copy-paste beats a paraphrase every time.
- What you've already tried — saves a round trip.
What's next
- FAQs — common questions and the pages that answer them.
- Terminology — what every platform term means in one place.
- Status — subscribe to live platform health updates.
- Reliability — the rollout behaviors that protect you from most deploy-time symptoms.