Start or stop your Azure Spring Apps service instance
Note
The Basic, Standard, and Enterprise plans will be deprecated starting from mid-March, 2025, with a 3 year retirement period. We recommend transitioning to Azure Container Apps. For more information, see the Azure Spring Apps retirement announcement.
The Standard consumption and dedicated plan will be deprecated starting September 30, 2024, with a complete shutdown after six months. We recommend transitioning to Azure Container Apps. For more information, see Migrate Azure Spring Apps Standard consumption and dedicated plan to Azure Container Apps.
This article applies to: ❌ Standard consumption and dedicated (Preview) ✔️ Basic/Standard ✔️ Enterprise
This article shows you how to start or stop your Azure Spring Apps service instance.
Your applications running in Azure Spring Apps may not need to run continuously. For example, an application may not need to run continuously if you have a service instance that's used only during business hours. There may be times when Azure Spring Apps is idle and running only the system components.
You can reduce the active footprint of Azure Spring Apps by reducing the running instances, which reduces costs for compute resources. For more information, see Start, stop, and delete an application in Azure Spring Apps and Scale an application in Azure Spring Apps.
To reduce your costs further, you can completely stop your Azure Spring Apps service instance. All user apps and system components are stopped. However, all your objects and network settings are saved so you can restart your service instance and pick up right where you left off.
Limitations
The ability to stop and start your Azure Spring Apps service instance has the following limitations:
- You can stop and start your Azure Spring Apps service instance to help you save costs. However, you shouldn't stop and start a running instance for service recovery - for example, to recover from an invalid virtual network configuration.
- The state of a stopped Azure Spring Apps service instance is preserved for up to 90 days. If your cluster is stopped for more than 90 days, you can't recover the cluster state.
- You can only start, view, or delete a stopped Azure Spring Apps service instance. You must start your service instance before performing any update operation, such as creating or scaling an app.
- If an Azure Spring Apps service instance has been stopped or started successfully, you have to wait for at least 30 minutes to start or stop the instance again. However, if your last operation failed, you can try again to start or stop without having to wait.
- For virtual network instances, the start operation may fail due to invalid virtual network configurations. For more information, see Customer responsibilities for running Azure Spring Apps in a virtual network.
Prerequisites
- An existing service instance in Azure Spring Apps. To create a new service instance, see Quickstart: Provision an Azure Spring Apps service instance.
- (Optional) Azure CLI version 2.45.0 or later.
Stop a running instance
In the Azure portal, use the following steps to stop a running Azure Spring Apps instance:
Go to the Azure Spring Apps service overview page.
Select Stop to stop a running instance.
After the instance stops, the status shows Succeeded (Stopped).
Start a stopped instance
In the Azure portal, use the following steps to start a stopped Azure Spring Apps instance:
Go to Azure Spring Apps service overview page.
Select Start to start a stopped instance.
After the instance starts, the status shows Succeeded (Running).
Troubleshoot failed resource provisioning during startup
When you start a service instance, you might get an error message even if the ProvisioningState is Succeeded. This error message helps you identify the resources that failed to start or the settings that weren't applied.
You might receive an error message similar to the following example: Failed to start the following resource(s) or apply setting(s): [<failed resource list>]. Please check and update them accordingly.
The following list describes some common actions you can take to recover from these failures:
- Identify the failed resources: Refer to the
<failed resource list>section in the error message to identify the resources that failed to start or the settings that failed to apply. - Investigate and mitigate: Examine each listed resource, check failure logs if available, and make necessary mitigations. These mitigations could involve updating the specific resources that failed to start or reapplying the affected settings.