RumataTroubleshoot with a clear next step
Find the failing layer before you restart, rebuild, or change data.
Step-by-step guidance.
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.
Start with the smallest useful evidence
- Write down what you tried, what happened, and what you expected.
- Record the time and whether you were in preview or the live site.
- Check the relevant resource status and Usage (opens in a new tab).
- Try a harmless minimal example if it can reproduce the issue.
- Share a redacted error and the reproduction steps with Rumata or your developer.
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
- Check whether the development machine is starting, queued, suspended, or ready.
- If it is suspended, use the workspace’s start/resume controls and wait for readiness.
- If it is ready, inspect the frontend output and the bound backend’s development status in Services.
- Check the running app’s configuration and whether it is listening as expected before redeploying infrastructure.
- 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 → Manage deployments. 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 (opens in a new tab) 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.