Query on Databricks apps idle time out

[A_Motia]

Question:

As of Today, Databricks Apps do not appear to have a generally available (GA) setting for automatic stopping or idle timeout. Although `compute_min_instances` and `compute_max_instances` are available in the CLI, these settings are still in Private Preview.

Currently, an app that remains running may continue to incur compute costs until it is manually stopped.

My questions are:

1. Is there a supported way to automatically stop a Databricks App after a period of inactivity?

2. Can this be achieved using the Databricks CLI, REST API, Jobs, or another automation mechanism?

3. Are there any recommended workarounds for development and testing environments to prevent unnecessary compute costs?

4. Is an idle timeout or automatic stop feature planned for general availability?

Any guidance or best practices for managing Databricks Apps compute costs would be greatly appreciated.

[SumeshKashyap · Accepted solution]

Hello @A_Motia 

Correct, there's no GA idle-timeout or auto-stop for Apps today. An app is billed for its compute size the whole time it's in the Running state, whether anyone uses it or not. The supported workaround is to stop it yourself on a schedule: a small job that calls the Apps stop API (CLI, REST or SDK) in the evening, plus an optional start in the morning. If you want real idle-based stopping, have the app record its last request and let the same job stop it when it's been quiet for N minutes.

On your questions:

- 1. No built-in setting yet. Stop/start is manual or scripted.

- 2. Yes, all three work: databricks apps stop <app-name>, POST /api/2.0/apps/{name}/stop, or w.apps.stop(name=...) in the Python SDK, which is the easiest to run from a scheduled job.

- 3. See the two patterns below. For dev, also pick the Medium compute size (cheaper than Large), and stop the app after each bundle deploy / test session, since deploying starts it.

- 4. I haven't seen a public GA date for scale-to-zero / compute_min_instances. Your account team can tell you whether you can join the preview.

Pattern 1, scheduled stop (simplest). A notebook task on serverless, scheduled e.g. 19:00 on weekdays. The job's run-as principal needs CAN MANAGE on the apps:

from databricks.sdk import WorkspaceClient

w = WorkspaceClient()

for name in ["my-dev-app", "my-test-app"]:

    app = w.apps.get(name)

    if app.compute_status and app.compute_status.state.value == "ACTIVE":

        w.apps.stop(name=name).result()

        print(f"stopped {name}")

A second job at 08:00 with w.apps.start(name=name) brings them back up if needed.

Pattern 2, stop after inactivity. Have the app write a heartbeat at most once every few minutes when it serves a request (e.g. Flask before_request or a Streamlit page load):

import time

from databricks.sdk import WorkspaceClient

_w, _last = WorkspaceClient(), 0

HEARTBEAT = "/Volumes/main/ops/app_heartbeat/my-dev-app.txt"

def touch_heartbeat():

    global _last

    if time.time() - _last > 300:

        _w.files.upload(HEARTBEAT, str(int(time.time())).encode(), overwrite=True)

        _last = time.time()

Then run the job every 30 minutes and stop the app when the timestamp is older than your threshold, e.g. 60 minutes:

ts = int(w.files.download(HEARTBEAT).contents.read())

if time.time() - ts > 3600:

    w.apps.stop(name="my-dev-app").result()

The app's service principal needs WRITE VOLUME on that volume. Docs: https://docs.databricks.com/aws/en/dev-tools/databricks-apps/ 

if this solves your problem, kindly accept this as an answer so that it is useful for the community.