Databricks Apps - "App Not Available" error with locationId parameter missing

[yutmurakami]

Hello,

I'm experiencing an issue with Databricks Apps where I cannot access my deployed app from a browser, even though the app appears to be running successfully.

**Symptoms:**
- Browser shows "App Not Available" error when accessing the app URL
- Console errors show:
- "BAD_REQUEST: Missing or invalid required parameter: locationId"
- "403 Forbidden on /ajax-api/2.0/apps/[app-name]"
- WebSocket connection failures

**Environment:**
- Workspace ID: 7474651874855137
- Workspace URL: https://dbc-629cd32b-8c5e.cloud.databricks.com
- App Name: mail-agent-ui-v2
- App URL: https://mail-agent-ui-v2-7474651874855137.aws.databricksapps.com
- Region: AWS

**What I've confirmed:**
✅App is successfully deployed (state: SUCCEEDED)
✅Streamlit server is running normally (verified in logs)
✅No errors in application logs
✅curl/Python requests return 302 redirect (OAuth flow starts correctly)
✅Tested from multiple browsers and networks (home Wi-Fi, mobile)
✅App compute shows: "App compute was stopped due to workspace or account status"

**Additional observation:**
The app was automatically stopped with the message "App compute was stopped due to workspace or account status", which suggests there might be a workspace or account-level restriction.

**Questions:**
1. Is there a workspace or account setting that needs to be enabled for Databricks Apps?
2. Could this be related to authentication/authorization at the workspace level?
3. Has anyone else experienced this locationId parameter error?

The app itself appears to be working correctly internally, but the OAuth authentication flow seems to fail when accessed from a browser.

Any help or suggestions would be greatly appreciated!

[ThomazNeto]

Hey — I think the answer is hiding in your own checklist, in that last item you marked with a ✓:

"App compute was stopped due to workspace or account status"

That's not a side observation, that's almost certainly your root cause. In Databricks Apps, *deployment* and *compute* are separate states. Your deployment can be SUCCEEDED (code packaged and published) while the app's compute is stopped — and a stopped app is simply not accessible from the browser. "App Not Available" is the expected page for that state, not a bug in your app. The Streamlit logs showing the server running normally are most likely from before the stop.

The 302 you get from curl doesn't contradict this either — that just means the ingress/OAuth layer in front of the app is up. It responds even when the compute behind it is down.

On the locationId error and the 403 on /ajax-api: I went looking and couldn't find any public documentation or thread on that locationId parameter. My read (opinion, not verified) is that both are console noise — internal workspace UI calls failing as a *consequence* of the app/account state, not the cause. I wouldn't spend time debugging those before sorting out the compute status.

So, to your questions:

1. It's less about a setting to enable and more about what "workspace or account status" means for your environment. What kind of workspace is this — Free Edition, trial, or paid? That changes everything:
- Free Edition: apps auto-stop after a period (24h has been cited), there's a one-app-per-account limit, and if you exceed the fair-usage quota, compute gets shut down for the rest of the day (or in extreme cases the month). All of these produce exactly the stop you're seeing, and all are recoverable — just restart later.
- Paid: Apps require Premium/Enterprise tier; they don't work on Standard by design.
- Trial: an expired trial or a billing/subscription issue at the account level would also surface as a stop "due to account status" — that one you'd check in the account console.

2. I don't think this is an auth problem. Your OAuth flow starting correctly (the 302) actually confirms that layer is fine.

3. See above — no public reference I could find, so you're probably looking at UI internals rather than something actionable.

What I'd do, in order: just try starting the app again (Start button in the Apps UI, or `databricks apps start <app-name>` from the CLI). If it was an auto-stop or a daily quota, that alone fixes it — or it fails with a clearer message, which is also progress. If Start keeps failing with the same "workspace or account status" message and your account/billing looks healthy, then it's a support ticket, and you already have everything they'll ask for (workspace ID, app URL, timestamps)

[yutmurakami]

Hi Thomaz,

Thank you so much for your detailed analysis! I followed your advice and tried the following:

**What I did:**
1. Created a fresh app with a new name (`mail-agent-test`)
2. Successfully started the compute (confirmed ACTIVE state)
3. Deployed the app (deployment status: SUCCEEDED)
4. Confirmed app status: RUNNING

**Current status:**
✅ Compute Status: ACTIVE
✅ App Status: RUNNING
✅ Deployment: SUCCEEDED
❌ Browser access: Still shows "App Not Available"

**Additional findings:**
When I test the app URL with Python requests, I can see that:
- The initial request returns HTTP 302 (redirect to OAuth)
- After following redirects, it lands on the Databricks login page
- The OAuth authentication flow doesn't complete successfully
- Final URL: `https://dbc-629cd32b-8c5e.cloud.databricks.com/login.html?login_redirect_mode=none&next_url=...`

**Key discovery:**
My workspace is on **Databricks Free Edition**. According to the documentation:
- Apps auto-stop after 24 hours (as you mentioned)
- Limited to 3 apps per account
- Subject to fair usage policy

**My question:**
Could there be an OAuth/authentication limitation specific to Free Edition that prevents browser access to apps, even when the app compute is running? The fact that the OAuth flow redirects to login (rather than completing authentication) suggests a permission or tier-related restriction rather than just a compute availability issue.

The locationId errors and 403s you mentioned as "console noise" are still appearing, but as you predicted, they seem to be symptoms rather than the root cause.

Has anyone else reported similar OAuth authentication issues with Databricks Apps on Free Edition?

Thanks again for your help!

[ThomazNeto]

Nice progress — with compute ACTIVE and the app RUNNING, we've eliminated the original cause and narrowed this down to the auth/access layer. A few thoughts:

First, one thing in your test that's easy to over-read: the Python requests behavior is actually *expected*, not evidence of a broken flow. requests has no browser session — no workspace cookies, no identity — so 302 → login page is exactly what should happen for an unauthenticated client. That test can't distinguish a healthy app from a broken one. The signal that matters is what happens in a browser where you're already logged into the workspace.

Second — and I'd test this before anything else, because it's cheap: the current Free Edition limitations page (updated July 20, 2026) says **one Databricks App per account**, and you now have at least two (the original mail-agent-ui-v2 plus the new mail-agent-test). You mentioned docs saying 3 — that may be the limit for LinkedIn-verified accounts, since verification raises some Free Edition limits, but the base limit documented today is one. Try deleting the old app so exactly one exists, restart the remaining one, and test the URL again. If the platform enforces the one-app limit somewhere in the serving/auth layer, that alone could explain an app that reports RUNNING but never becomes reachable.

If that doesn't fix it, the key question for diagnosis: in your logged-in browser, when you open the app URL in a new tab, what's the exact sequence? Two very different failure modes:

(a) You get bounced to login, authenticate successfully, and *then* land on "App Not Available" — that smells like an authorization/provisioning problem (your hypothesis).

(b) You see "App Not Available" immediately without completing a login round-trip — that's more like the OAuth handshake between the two domains failing.

If it's (b): the app lives on *.databricksapps.com while auth happens on *.cloud.databricks.com — a cross-site flow. Browser privacy features (third-party cookie blocking, tracking prevention, extensions) can break exactly this kind of handshake. I know you tested multiple browsers, but one run in a clean incognito window with shields down, logging in fresh, rules it out cheaply. Also try opening the app via the Open button on the app's page in the workspace UI (Compute > Apps) rather than pasting the URL — same destination, but it guarantees you arrive from an authenticated session.

On your actual question — a Free Edition-specific OAuth restriction for Apps — I can't confirm or deny it from public docs, and I found no other reports of this exact symptom this month. What I *can* say is that tier-based OAuth provisioning restrictions demonstrably exist on Free Edition: in a recent thread, a Databricks architect confirmed the Genie mobile OAuth app simply isn't provisioned for Free Edition accounts, and login fails at exactly that layer. Different OAuth client, but the same category of restriction — so your hypothesis isn't far-fetched. That said, Apps are officially supported on Free Edition (within the limits above), so browser access breaking by design would be strange.

[yutmurakami]

Hi Thomaz,

Quick update: I followed your recommendation exactly.

**What I did:**
✅Deleted both old apps → only 1 app remains (Free Edition limit met)
✅Restarted the app
✅Current state: Compute ACTIVE, App RUNNING, Deployment SUCCEEDED

**Result:**
❌Still "App Not Available" in browser
❌Edge DevTools shows 502 Bad Gateway (not just OAuth redirect)

**Key evidence:**
- Internal logs: "Deployment successful", Streamlit running on port 8080
- The app works perfectly internally
- OAuth authentication passes (502 means auth succeeded but proxy can't reach backend)
- Only browser access fails

**Conclusion:**
Even with 1 app (limit met), compute running, and successful deployment, the Databricks Apps proxy cannot route traffic to the Streamlit backend on Free Edition.

This appears to be a **Free Edition infrastructure limitation** — not just OAuth provisioning, but the entire Apps serving layer may not be fully enabled for Free Edition, despite docs saying "up to 1-3 apps supported."

Has anyone actually confirmed successful **browser access** to Databricks Apps on Free Edition? Or is this feature deployment-only (no public access)?

Thanks for all your help!

[ThomazNeto]

Hi @yutmurakami — I can now answer your question with data instead of hypotheses. I ran your exact scenario on my own Free Edition workspace (also AWS, different workspace than yours), twice.

Test 1: existing app on my Free Edition workspace — Running/Active, and the *.aws.databricksapps.com URL renders the full interactive UI in the browser. No "App Not Available", no 502.

Test 2 (to rule out luck and age of the app): created a brand-new app today from the untouched Streamlit hello-world template. Deployed at 08:09, Running, and the browser rendered it within two minutes of creation — slider, chart, fully interactive.

So, to your direct question — "has anyone actually confirmed successful browser access to Databricks Apps on Free Edition?" — yes, confirmed today, Aug 3 2026. It is not deployment-only: the entire serving path (OAuth → proxy → app backend) works on this tier. The general claim that the Apps serving layer isn't enabled for Free Edition is refuted.

Two more things my tests surfaced:

1. The app-count question you raised ("1-3 apps?"): both my apps coexist and run on ONE Free Edition account — which isn't even identity-verified. So the documented one-app-per-account limit isn't being enforced as of today, and app count was almost certainly never your problem. My earlier suggestion to delete apps was a red herring — apologies for the detour; at least it eliminated a variable.

2. What my tests CANNOT close, stated honestly: my workspace/account is ~5 months old; yours is recent. A new app on an old workspace doesn't test what a newly created workspace gets provisioned with. That's now the only variable left standing — and it would neatly reconcile everything we've both observed: if Apps ingress provisioning is incomplete (or changed) for recently created Free Edition workspaces, mine works and yours 502s, exactly as we see.

Which means your case is now extremely well-defined for escalation. I'd post this in the Free Edition Help board, where Databricks staff answer provisioning questions:

"Apps browser access + multiple concurrent apps confirmed working on a ~5-month-old Free Edition account (AWS, Aug 2026, second-party test in this thread). My recently created Free Edition workspace gets 502 from the Apps proxy AFTER successful OAuth, with app RUNNING, deployment SUCCEEDED, single app, and all app-side causes eliminated (including port/address overrides). Is Apps ingress fully provisioned for newly created Free Edition workspaces? Could you check provisioning for workspace [your ID]?"

That's a question they can answer with one look at their side of the wall. You did the elimination work; the comparison data now exists; the rest is theirs. If you post there, drop the link here — the resolution will be useful for the next person who hits this.