Start, stop, and open an app
Run an app, distinguish wake from deploy, and recover from startup problems.
Use the lifecycle strip in Overview to control an app's running sandbox. The action label follows its state: Deploy creates the initial environment, Start resumes a stopped app, and Wake starts an asleep on-demand app.
Start and open
- Open the app workspace and choose Overview.
- Choose Deploy, Start, or Wake, as offered.
- Wait for deployment and readiness checks to complete.
- Use the embedded app or choose Open to launch it separately.
A Running status describes the runtime state, but the browser route can need a little more time before it serves the interface. Wait for Open to become ready rather than repeatedly starting the app. If the readiness check times out, review the offered retry or open options and the current status before acting.
The permanent app address is suitable for bookmarks and distribution. Access at that address still follows the app's sharing settings. Some apps open in a separate view instead of embedding in Overview.
Stop
Choose Stop to tear down the running sandbox. The app record remains available, along with its stored definition and referenced resources. For Always on and Timed apps, it stays stopped until explicitly started again. For On demand, the next visit can wake it automatically; Stop is not a permanent access revocation in that mode.
Wait for a stop to finish before starting again. Controls are disabled during conflicting operations so a second request cannot silently race the first.
Reload is different
Reload app reloads the embedded browser frame. It does not restart the app, rebuild its environment, extend its lease, or rerun workflows. Use it when the frame needs a fresh load of the current running experience.
If deployment fails, inspect the displayed error and verify required runtime, workflow, and connection capabilities. Starting cannot repair a removed data-source target. Use App troubleshooting and Workflows and connections to diagnose the underlying issue.