Pre-Flight to Live Site: pxhtr's Essential Checklist for Your Azure App Service Deployment

Every deployment to Azure App Service carries risk. A missing environment variable, an incorrect SKU, or a forgotten health endpoint can turn a routine release into an incident. Over the years, we've seen teams—from startups to enterprises—make the same predictable mistakes. This checklist is designed to catch those before they reach production. Think of it as your pre-flight inspection: systematic, repeatable, and grounded in real-world failures.

Who Needs This Checklist and When to Use It

This checklist is for anyone responsible for deploying code to Azure App Service—whether you're a solo developer pushing a side project, a DevOps engineer managing multi-region deployments, or a team lead reviewing release procedures. The ideal time to run through it is before every production deployment, but especially when:

• You're deploying to a new App Service Plan or resource group.
• You've made infrastructure changes (scaling, networking, or authentication).
• You're migrating from another platform or from an on-premises environment.
• It's been more than a month since the last deployment.

The cost of skipping this checklist is rarely immediate. It often manifests as a slow leak: intermittent timeouts, gradual performance degradation, or a security review that flags a misconfigured CORS policy. By the time you notice, the fix is urgent and the root cause is buried in a dozen commits.

We've structured the checklist into eight sections, each covering a critical domain: plan and sizing, deployment slots, configuration and secrets, networking, monitoring, security, CI/CD pipeline, and post-deployment verification. You don't have to follow them in strict order—but each section builds on the previous one. Start with the foundation (plan and sizing) and work your way up.

For teams using Infrastructure as Code (IaC), we recommend embedding these checks into your pipeline as validation steps. For example, a bicep or ARM template can enforce that staging slots exist and that auto-swap is enabled. But even if you deploy manually, a printed or digital checklist run by a second reviewer catches more issues than a solo click-through.

Plan and Sizing: Matching Capacity to Traffic Patterns

Choosing the wrong App Service Plan tier is the most common—and most expensive—mistake we see. The free and shared tiers are fine for development and testing, but they have severe limitations: no custom domains, no SSL, and no SLA. For production, you need at least the Basic tier, and for any real-world traffic, Standard or Premium is usually necessary.

But even within a tier, the number of instances and the size of each instance matter. A single B1 instance might handle 100 concurrent users with a simple API, but a compute-heavy app with image processing will saturate its CPU in minutes. We recommend starting with a load test that mirrors your expected peak traffic—use Azure Load Testing or a third-party tool like k6. Run it against a staging slot, not production, and watch for CPU, memory, and response time thresholds.

Right-Sizing Checklist

• Estimate peak concurrent users and average request duration.
• Choose a tier that supports your scaling needs (Premium v3 for low latency and high density).
• Enable autoscaling based on CPU or memory, but set minimum and maximum limits to avoid cost surprises.
• Test with a realistic workload before the first production deployment.

One team we worked with provisioned a P1v2 instance for a customer-facing dashboard. During a marketing campaign, traffic spiked 10x, and the single instance hit 100% CPU. Autoscaling was configured but with a cooldown period of 30 minutes—too slow. The site became unresponsive for 20 minutes until they manually scaled out. After that incident, they switched to Premium v3 with instance-level health checks and a 5-minute cooldown. The lesson: test your scaling policy with a simulated spike, and don't assume the default settings are adequate.

Another common oversight is forgetting to reserve instances for staging slots. Each slot runs on the same App Service Plan and consumes resources. If you have two staging slots plus production, you need enough capacity to run all three simultaneously during a swap. Otherwise, the swap can fail or cause throttling.

Deployment Slots: Staging, Swapping, and Auto-Swap

Azure App Service deployment slots are one of the platform's best features—they let you validate a build in a staging environment before swapping it into production. But they're not a silver bullet. We've seen teams use slots but skip warmup, or enable auto-swap without proper health checks, leading to a brief outage during the swap.

The core workflow is straightforward: deploy your code to a staging slot, run smoke tests, then swap with production. The swap operation preserves the production slot's settings (like connection strings) if they're marked as slot-sticky. That's a double-edged sword: you can keep production secrets out of staging, but you must ensure your app reads the correct configuration after the swap.

Slot Configuration Essentials

• Mark all environment-specific settings as slot-sticky (connection strings, API keys, certificate thumbprints).
• Enable auto-swap only if you have a health check endpoint that returns 200 within a reasonable timeout.
• Use the swap preview feature to validate configuration before committing the swap.
• Test the warmup endpoint—your app's root URL or a dedicated /health—to ensure it responds correctly after the swap.

A common pitfall is forgetting to update the staging slot's configuration after a swap. For example, if you swap staging and production, the staging slot now holds the old production code. If you deploy a new build to staging without resetting its configuration, you might accidentally push stale settings to production on the next swap. We recommend automating a config sync after each swap, or using a pipeline that deploys fresh configs with every release.

Another issue: slot-swapping doesn't automatically drain existing connections. If your app uses long-lived WebSocket connections or SignalR, those connections are lost during the swap. Plan for graceful disconnection and reconnection in your client code. For HTTP traffic, Azure provides a warmup mechanism that sends a request to the root of the app before the swap completes—but only if you've configured the applicationInitialization section in your web.config or app settings.

Configuration and Secrets: Don't Hardcode, Don't Forget

Hardcoded connection strings and API keys are a security risk and a maintenance headache. Azure App Service offers several secure storage options: App Settings, Key Vault references, and Managed Identity. We strongly recommend using Key Vault references for any secret that can change independently of your code—database passwords, third-party API keys, certificates.

But even with Key Vault, there are traps. The App Service must have a Managed Identity assigned and the correct Key Vault access policy. If you move the App Service to a different resource group or subscription, the identity changes, and you'll need to update the access policy. Also, Key Vault references are resolved at runtime, so if the vault is unreachable (e.g., due to a network restriction), your app will fail to start.

Secrets Management Checklist

• Use Managed Identity for Azure resources (like SQL Database or Storage) where possible.
• Store all non-Azure secrets in Key Vault and reference them via @Microsoft.KeyVault() syntax.
• Set slot-sticky on any setting that differs between slots (production vs. staging).
• Audit secrets quarterly: rotate keys, remove unused entries, and verify access policies.

One scenario: a team stored a third-party payment gateway API key as an App Setting, not as a slot-sticky setting. When they swapped staging to production, the staging slot's key (pointing to a sandbox environment) replaced the production key. Payments failed for 15 minutes before they noticed. The fix was to mark the setting as slot-sticky and update the production slot's value separately. This is a classic mistake—and it's entirely avoidable with a checklist.

Another nuance: environment variables set in the Azure portal take precedence over those in your app's configuration files (like appsettings.json). This is useful for overriding settings in production, but it also means that a stale portal setting can override your latest code change. We recommend keeping portal settings minimal and using them only for environment-specific values; everything else should be in your code repository with appropriate defaults.

Networking: VNet Integration, DNS, and Custom Domains

Networking misconfigurations are among the hardest issues to diagnose because they often manifest as intermittent timeouts or partial failures. Azure App Service supports several networking features: VNet integration (regional and gateway-required), IP restrictions, and private endpoints. Each has its own prerequisites and limitations.

For apps that need to access resources inside a virtual network (like a SQL Database or a Redis cache), you need VNet integration. The regional VNet integration is simpler and doesn't require a gateway, but it only works with App Service plans in the newer Premium v2/v3 tiers. If you're on a standard plan, you'll need the gateway-required integration, which adds latency and complexity.

Networking Pre-Flight Checks

• Verify that the VNet integration subnet is delegated to Microsoft.Web/serverFarms and has enough IP addresses.
• Test connectivity from the App Service to your backend services using the Kudu console or a simple test endpoint.
• If using private endpoints, ensure DNS resolution works (private DNS zones must be linked to the virtual network).
• Check that your custom domain is verified and the SSL certificate is bound correctly.

A common failure point: the custom domain verification step. You add a TXT record to your DNS provider, but the record takes time to propagate. If you try to add the domain in Azure before propagation, it fails. We recommend adding the TXT record at least 30 minutes before attempting the domain binding. Also, if you're using Azure Front Door or Traffic Manager, the domain binding process is slightly different—you need to verify the domain at the Front Door level first.

Another issue: IP restrictions. You can restrict inbound traffic to your App Service by IP address or range. But if you have a load balancer or CDN in front, the client IP might be masked. Use the X-Forwarded-For header to get the real client IP, and configure your IP restrictions to accept traffic from the load balancer's IP range. Otherwise, you might block legitimate traffic.

Monitoring and Alerts: Knowing Before Your Users Do

You can't fix what you don't measure. Azure App Service provides built-in metrics (CPU, memory, requests, errors) and logs (application, web server, detailed error). But the default dashboards are often insufficient for production. We recommend setting up Application Insights for your app—it gives you end-to-end transaction tracing, dependency tracking, and proactive detection of anomalies.

Beyond metrics, you need alerts. The most critical alerts are: HTTP 5xx errors, response time > 5 seconds, and CPU > 90% for 10 minutes. But don't alert on every spike—use dynamic thresholds that adapt to your baseline. Azure Monitor offers smart detection for failure anomalies and performance degradation.

Monitoring Setup Checklist

• Enable Application Insights with sampling to control cost.
• Set up availability tests (ping or multi-step) from multiple locations.
• Create alert rules for HTTP 5xx, high latency, and low availability.
• Configure log retention and export to a Log Analytics workspace for long-term analysis.

One team we advised had monitoring but no alerts. They discovered a memory leak only when users complained on social media. After implementing alerts, they caught the same leak during a staging deployment and fixed it before swap. The cost of setting up alerts is negligible compared to the cost of a public outage.

Another tip: use the App Service's built-in diagnostic settings to stream logs to a storage account or Event Hub. This helps with post-mortem analysis and compliance. But be careful with log volume—set a retention policy to avoid storage costs.

Security: Authentication, TLS, and Managed Identity

Security is not a one-time configuration; it's a continuous process. For Azure App Service, the basics are: enforce HTTPS, use TLS 1.2 or higher, and enable client certificate authentication if needed. But there are deeper considerations, especially around authentication and authorization.

Azure App Service has built-in authentication (EasyAuth) that integrates with Azure AD, Facebook, Google, and others. It's convenient, but it can be a black box. If you need fine-grained control over the authentication flow (like custom claims or token validation), consider using a middleware library like Microsoft.Identity.Web instead.

Security Checklist

• Enforce HTTPS only (disable HTTP).
• Set the minimum TLS version to 1.2.
• Use Managed Identity for accessing Azure resources instead of keys.
• Regularly review access policies for the App Service (RBAC) and Key Vault.
• Enable audit logging for management operations.

A common oversight: failing to rotate certificates. App Service supports automatic certificate rotation for App Service Managed Certificates, but if you bring your own certificate, you must renew it manually. Set a calendar reminder 30 days before expiration. Also, if you use a certificate for client authentication, ensure the certificate chain is correctly uploaded.

Another risk: over-permissioned RBAC roles. Developers often get Contributor or Owner roles on the App Service resource group, which allows them to change networking settings or delete resources. Follow the principle of least privilege: use the built-in roles like Website Contributor or Reader, and create custom roles for specific needs.

CI/CD Pipeline Validation: Automate the Checks

Your deployment pipeline should include automated checks that mirror this checklist. For example, in a GitHub Actions workflow or Azure DevOps pipeline, you can run a script that validates the App Service configuration before deploying. This catches drift—when someone manually changes a setting in the portal that your pipeline doesn't know about.

We recommend a two-stage approach: first, run a pre-deployment validation that checks the current state of the App Service (tier, slots, settings, networking). Then, after deployment, run a post-deployment smoke test that verifies the app is responding correctly and that the configuration matches expectations.

Pipeline Validation Steps

• Use Azure CLI or PowerShell to export the App Service configuration and compare it to a known good baseline.
• Run a health check endpoint with expected response status and body.
• Verify that staging slot exists and has auto-swap enabled (if using that pattern).
• Check that all required App Settings and connection strings are present and not empty.

One team automated their entire checklist as a series of Azure CLI commands in their pipeline. The pipeline would fail if any check failed—like missing slot-sticky settings or an incorrect TLS version. This eliminated the human error factor and made deployments predictable.

But automation has limits. Some checks, like load testing or security scanning, are better suited for periodic runs rather than every deployment. We recommend running a full load test weekly and a security scan monthly, integrated into your pipeline but not blocking every commit.

Mini-FAQ: Common Questions About Azure App Service Deployments

Do I need deployment slots for a simple API?

Yes, even for a simple API. Deployment slots let you validate the new version before it serves live traffic. At minimum, use a staging slot for manual testing. The swap operation is nearly instantaneous, so the overhead is minimal. The only exception is if your app is stateless and you can roll back quickly via a previous deployment artifact.

How do I handle sticky sessions (ARR affinity)?

ARR affinity is enabled by default. If your app uses in-memory session state, you need sticky sessions. But for better scalability, move session state to an external store like Redis Cache or SQL Server. Then you can disable ARR affinity and scale out without worrying about session loss.

What about certificate renewal for custom domains?

If you use an App Service Managed Certificate, renewal is automatic. If you bring your own certificate, you must upload the new certificate and update the binding before expiration. Use Azure Key Vault to store the certificate and configure automatic rotation if possible. Set up an alert for certificate expiration (you can monitor the remaining days in Azure Advisor).

Can I deploy directly to production without a slot?

Technically yes, but we advise against it. Direct deployment to production means any issue immediately affects users. Even if you have a rollback plan, the time to redeploy a previous version is longer than a slot swap. The only scenario where direct deployment might be acceptable is a single-instance development environment with no users.

Recap: Your Next Three Moves

By now, you have a comprehensive checklist. But a checklist is only useful if you use it. Here are three concrete steps to take today:

1. Run a baseline audit of your current App Service configuration. Use the Azure portal or CLI to export settings and compare them against the checklist. Identify gaps in slot configuration, secret management, and monitoring.
2. Set up one missing alert that you don't have today—likely HTTP 5xx errors or high CPU. Configure it to send a notification to your team's chat or email. This single alert can save you hours of downtime.
3. Automate one validation check in your deployment pipeline. Start with a simple health check after deployment. Once that works, add a configuration drift check. Over time, build up to a full pre-flight validation.

Deployments are never risk-free, but a structured checklist reduces the probability of common failures. Every item on this list comes from real incidents we've seen or read about. Use it, adapt it to your context, and share it with your team. The goal is not to eliminate all risk—that's impossible—but to make each deployment a little more predictable than the last.