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.