# Troubleshoot with a clear next step
Find the failing layer before you restart, rebuild, or change data.
Source: https://docs.rumata.dev/guides/troubleshooting
Reviewed: 2026-11-01
## Before you start
- The visible error or symptom.
- The action and screen that produced it.
## The page opens, but its API or worker fails
| Symptom | Check next |
| --- | --- |
| Frontend works but API calls fail | Open System Explorer → Services. Inspect the correct development or production service, its logs, endpoint, port and readiness. Check the frontend binding; a website deployment alone does not deploy every dependency. |
| Private preview returns 403 before the app handles the request | Use the authorized Studio preview or backend debug tool. Private development requires Rumata authorization even when the deployed application is public. Publishing is not a workaround. |
| Service reports starting or wakes slowly | Wait for readiness and test a real application request. Check capacity and dependency status. A starting response is not a completed deployment. |
| Data disappeared or appears in both environments | Verify the selected database, factory schema and actual records. Development and production can share a database binding; preview is not automatically a disposable data copy. |
| A background worker stops and never wakes | Check its runtime policy. An HTTP-disabled worker cannot wake from a request; continuous workers need an appropriate policy such as Always on. |
| A source build fails repeatedly | Read that build’s logs and selected source revision. Check Dockerfile/context paths, locked dependencies and build commands before requesting another build. |
Verify application sign-in and ownership separately from Rumata resource access. A successful health check does not prove database reads, user authorization or file operations. See [Backend services](https://docs.rumata.dev/guides/backends).
## Start with the smallest useful evidence
1. Write down what you tried, what happened, and what you expected.
2. Record the time and whether you were in preview or the live site.
3. Check the relevant resource status and [Usage](https://app.rumata.dev/usage).
4. Try a harmless minimal example if it can reproduce the issue.
5. Share a redacted error and the reproduction steps with Rumata or your developer.
> **Keep support evidence safe**
> Do not include passwords, secret values, session tokens, full private records, or payment details in screenshots or logs. Share resource identifiers through an appropriate private support channel.
## I cannot enter my workspace
| Symptom | Next step |
| --- | --- |
| Approval pending | Your account exists. Automatic approval depends on registration capacity; otherwise wait for administrator approval or contact Support. Avoid duplicate registration. |
| Wrong or missing factories | Check the signed-in identity and project permissions. |
| Invitation missing | Check the exact Rumata nickname and signed-in recipient account. A new account’s nickname may be its email address; older accounts may differ. Check whether the invitation was already accepted or declined. |
| Google sign-in unavailable | Use an existing supported sign-in method or try the normal login page in a browser with Google sign-in enabled. Do not create a second identity accidentally. |
## The preview is loading or blank
1. Check whether the [development machine](https://docs.rumata.dev/guides/development#machine) is starting, queued, suspended, or ready.
2. If it is suspended, use the workspace’s start/resume controls and wait for readiness.
3. If it is ready, inspect the frontend output and the bound backend’s development status in Services.
4. Check the running app’s configuration and whether it is listening as expected before redeploying infrastructure.
5. Once the cause is fixed, reload the preview and repeat the user journey.
A preview problem does not automatically mean the published frontend is down. Open the actual live URL separately.
## A workflow failed
Open the failed run and find the first failing node. Inspect its input, required configuration, error, and dependency status. Check permission and allowance messages. Avoid rerunning a workflow that sends messages, charges money, or writes records until you understand whether a prior attempt already performed those actions.
## A database or file operation failed
| Symptom | Next step |
| --- | --- |
| Database starting | Allow the current lifecycle operation to finish and watch the status. |
| Permission denied | Check the actor, target resource, group membership, and inherited grants. |
| Upload too large or capacity exceeded | Check individual-file restrictions, used/reserved capacity, and account allowance. |
| Missing old run details | Check history retention and saved-history limits. |
| SQL error | Check the exact table/column names, parameter values, and statement; do not recreate the database. |
## A release did not appear
Open [Frontend](https://docs.rumata.dev/guides/controls-frontend#frontend) → [Manage deployments](https://docs.rumata.dev/guides/controls-frontend#frontend). Compare the intended source revision with the latest attempt and the active live version. A successful local preview, queued deployment, or completed build is not the same as a successful live release. Read the failed deployment stage before retrying.
## Ask for help with enough context
Use the [Support](https://app.rumata.dev/contact) link in Rumata or rumata.dev/contact. Include a short title, affected screen, approximate time and time zone, preview/live distinction, redacted error, and reproduction steps. Explain whether the problem affects one user, one factory, or every project.
## Related guides
- [Navigate your workspace](https://docs.rumata.dev/guides/workspace)
- [Code and development machines](https://docs.rumata.dev/guides/development)
- [Publish your app](https://docs.rumata.dev/guides/publishing)
- [Understand plans and usage](https://docs.rumata.dev/guides/billing)