Troubleshooting Applications Connection Errors
When RAPTIX cannot complete the Applications data load, it replaces the normal interface with Couldn't load Applications and a Try again button. This state can result from a network interruption, an expired session, or an unavailable Applications dependency. It is different from an Access restricted message.
Before you start
- Keep the failing tab open until you note the time and the state you saw.
- Do not clear all browser data as a first step; that can remove useful session context without fixing a service outage.
- If the message says Access restricted, use Troubleshooting Applications Access instead.
Recover from Couldn't load Applications
- Select Try again once. This reruns the Applications load without requiring you to leave the page.
- If the normal header and workspace content appear, continue working.
- If the same full-page error returns, open another RAPTIX area such as Home in a separate tab.
- If other RAPTIX areas also fail or send you to sign-in, restore your connection and sign in again.
- If other areas work, reload the Applications browser tab once.
- If the problem persists, sign out of RAPTIX, sign back in, and open
/applicationsagain. - Report a repeated failure to your administrator with:
- The approximate UTC or local time.
- Your RAPTIX workspace name.
- Whether Home and other RAPTIX areas worked.
- Whether Try again, reload, and a new session changed the result.
- Your browser and device type.
Do not include authentication parameters, passwords, integration secrets, or screenshots containing sensitive application data.
Separate full-page failures from other problems
| What you see | Classification | Next step |
|---|---|---|
| Couldn't load Applications with Try again | Applications data-load failure | Follow the recovery steps above. |
| Access restricted and no workspace grid | Applications explorer access is missing | Follow the access troubleshooting guide. |
| Normal Applications header, but no matching cards | Empty search result or resource access issue | Clear search, then ask an administrator to review the item. |
| Workspace and page cards load, but one page opens blank | Target-page or authenticated-handoff problem | Reopen the page and follow the page-opening guide. |
| A page opens at sign-in | RAPTIX session or App Builder handoff problem | Confirm your RAPTIX session and open it again from Applications. |
About the header health badge
An Enterprise workspace can show a data-service health badge after Applications loads successfully. The badge reflects the backing service response returned during that load.
- A visible healthy badge confirms that check succeeded for the current load.
- A missing badge does not prove an outage: the badge is not available for every plan or state.
- When the initial load fails, RAPTIX shows the full-page error instead of an error-colored header badge.
Use Try again and service monitoring as the primary evidence; do not diagnose a failure from badge absence alone.
Administrator investigation
- Reproduce the issue with the affected workspace and, where safe, a user with comparable access.
- Determine the blast radius: one user, one browser, one workspace, one plan, or all Applications users.
- Confirm that the RAPTIX web application and Applications APIs are reachable from the affected environment.
- Check authentication and authorization responses for the affected session. A session failure and an Applications dependency failure require different fixes.
- For Enterprise workspaces, verify the App Builder data service and configured base address are healthy and reachable from RAPTIX.
- Check recent deployment, certificate, DNS, proxy, and configuration changes around the first reported time.
- Review server-side monitoring and logs using the request time and affected workspace. Applications activity logs can show recent successful user actions, but they are not a replacement for service logs.
- After remediation, use Try again from the affected account and verify that workspaces, applications, pages, and permitted header actions load.
Individual page does not open
If Applications itself loads normally but Open produces a blank page, sign-in prompt, or target error:
- Close the target tab or window.
- Confirm that the RAPTIX Applications tab still has an active session.
- Select Open again.
- Allow pop-ups and redirects for
https://<workspace>.raptix.appif the browser blocked the target. - Try another available page. If only one page fails, report its workspace, application, and page names to the application owner.
- If all App Builder pages fail while runnable RAPTIX forms work, report that distinction to the administrator.
See Opening and Using an Application Page for the complete page-opening flow.
Frequently asked questions
Should I keep selecting Try again?
No. Try once, then check another RAPTIX area and reload or renew your session. Repeated rapid retries do not add useful diagnostic information.
My colleague can open Applications. Is the service healthy?
It narrows the problem but does not prove every workspace, access path, or browser session is healthy. Include that comparison in your report.
Can Activity Logs tell me why Applications failed to load?
Not reliably. They record Applications interactions. Use platform and service logs for the underlying failure.
Should I use the old Applications URL?
No. Use the canonical /applications route on your RAPTIX workspace domain.