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

Introduction: The Cost of Skipping the Pre-Flight Check

In the rush to deliver features, the final steps before an Azure App Service goes live are often treated as a mere formality. A quick configuration tweak, a click of the "Deploy" button, and the team holds its breath. This approach, while common, trades short-term speed for significant long-term risk. Unexpected downtime, data leaks, or severe performance issues post-launch are almost always symptoms of a missed pre-flight check. This guide is designed for developers, DevOps engineers, and team leads who understand that a successful deployment is a process, not an event. We will walk through a structured, essential checklist that acts as a final gatekeeper. Our perspective is rooted in practical how-to guidance and actionable lists, avoiding theoretical deep-dives in favor of steps you can implement immediately. Consider this your co-pilot's manual, ensuring that when your application takes off into the production environment, it's built to handle turbulence. The framework we present reflects widely shared professional practices as of April 2026; always verify critical details against the latest official Azure documentation for your specific scenario.

Why a Checklist? Moving from Ad-Hoc to Systematic

Checklists force consistency and completeness in complex, high-stakes environments. For deployment, they combat cognitive overload and ensure that critical, yet easily forgotten, tasks are never skipped. A typical project might involve multiple team members with different focus areas; a shared checklist becomes a single source of truth. It transforms deployment from a heroic individual effort into a reproducible, team-based procedure. This is not about bureaucracy; it's about creating a safety net that catches the small oversights that lead to big problems.

The Core Philosophy of This Guide

Our approach is diagnostic and preventive. Instead of just listing settings, we explain the "why" behind each check. What failure mode does this setting prevent? What trade-off are you making by enabling or disabling a feature? We prioritize checks that have a high impact on stability, security, or cost. The goal is to equip you with the judgment to adapt this checklist to your application's unique needs, not to blindly follow a rigid script.

Who This Guide Is For (And Who It's Not For)

This guide is ideal for teams deploying business applications, internal tools, or customer-facing web services on Azure App Service. It assumes familiarity with core Azure concepts and the basics of the deployment pipeline. It is less suited for highly specialized, real-time streaming applications or massive-scale microservice architectures that require custom, platform-level engineering; though many principles will still apply, the implementation details will differ.

A Composite Scenario: The Midnight Page

Imagine a team that deployed their new customer portal. The deployment succeeded, and initial tests passed. At 2 AM, the site becomes unresponsive. The frantic investigation reveals the application is crashing due to a missing environment variable that was only set in the development slot, not propagated to production. The database connection string was wrong. A simple pre-flight check of environment configuration comparison would have caught this. This guide is designed to prevent exactly that kind of stressful, costly scramble.

How to Use This Checklist

Treat this as a living document. Integrate it into your deployment pipeline—as a manual gate in your CI/CD process, a runbook for a release manager, or a peer-review checklist. The most effective teams don't just read it; they operationalize it. We recommend running through it for every deployment, especially those involving infrastructure changes.

Setting Realistic Expectations

No checklist can guarantee a perfect deployment. Unexpected issues will arise. However, a thorough pre-flight check dramatically reduces the probability of common, preventable failures. It shifts your team's post-launch focus from firefighting to monitoring and optimization, which is where it should be.

Transition to the Core Checklist

With that context established, let's move from philosophy to practice. The following sections break down the essential pre-flight checks into logical domains, starting with the foundation of any deployment: your environment configuration.

Stage 1: Environment and Configuration Validation

Before a single byte of your application code is deployed, the target environment must be correctly provisioned and configured. Misconfiguration here is a leading cause of deployment failures. This stage is about ensuring the App Service plan, the service itself, and all dependent resources are in the expected state and ready to receive your workload. We go beyond checking for existence and delve into the specifics of sizing, networking, and integration that directly impact application behavior. A common mistake is assuming the production environment is a perfect copy of staging; subtle differences in SKUs, firewall rules, or private endpoint configurations can have dramatic consequences. This section provides a systematic way to validate those assumptions, turning guesswork into verified fact.

App Service Plan: Sizing and Scaling Readiness

Verify the App Service Plan SKU (e.g., P1v3, S1) matches your performance and scaling requirements. A critical check is ensuring auto-scaling rules are configured but disabled for initial deployment to prevent unexpected scale events during the launch volatility. Confirm the region is correct and that the plan has sufficient capacity (no quota issues). For production workloads, avoid shared (F1, D1) plans due to their resource constraints.

Application Settings and Connection Strings

This is the most frequent source of post-deployment bugs. Systematically compare all application settings and connection strings between your staging/pre-production slot and the production target. Pay special attention to keys, endpoints, and feature flags. Use a diff tool or a script to automate this comparison. Never rely on manual memory. Ensure all production secrets are stored in Azure Key Vault and referenced correctly, not stored as plain text in configuration.

Custom Domains and TLS/SSL Bindings

If your live site uses a custom domain, verify the DNS CNAME or A record is pointed to the correct App Service hostname well in advance. Check that the TLS/SSL certificate is uploaded, assigned to the correct domain, and not nearing expiration. For certificates from Key Vault, confirm the App Service managed identity has the correct GET permission. A missing or invalid SSL binding will cause immediate browser security warnings for your users.

Networking and Access Restrictions

Review Network Access Restrictions (formerly IP restrictions) and Virtual Network Integration settings. A classic error is deploying an update only to find the application cannot reach its database because a new outbound IP address hasn't been whitelisted on the downstream firewall. If using Private Endpoints, validate the private DNS zone resolution is working from within the App Service context.

Backup Configuration

Ensure automated backups are configured for the production App Service, with a retention policy that meets your business's Recovery Point Objective (RPO). Verify the backup storage account is in the same region and that the schedule does not conflict with your deployment window to avoid performance contention.

Deployment Slot Configuration

If using deployment slots (highly recommended), confirm the slot swap configuration is correct. Check which settings are marked as "slot setting" (sticky to the slot) versus swapped. Typically, connection strings and instrumentation keys should be sticky to ensure the swapped-in production slot retains its production connections.

Managed Identity and Role Assignments

If your app uses a system-assigned managed identity to access other Azure resources (like SQL Database or Storage), verify the identity is enabled and has the necessary role assignments (e.g., Storage Blob Data Contributor) on the target resources. Permissions are often overlooked during environment replication.

Validation Script or Runbook

Consider creating a simple PowerShell or Azure CLI script that performs these checks programmatically as part of your release pipeline. This script can check plan SKU, compare settings, test DNS resolution, and validate network connectivity to key dependencies, providing a fast, automated pre-flight report.

Stage 2: Security and Compliance Hardening

Security is not a feature you bolt on after launch; it's a fundamental property of your deployment configuration. This stage focuses on the essential security controls specific to Azure App Service that are often left at default, insecure values. We address identity, data protection, attack surface reduction, and compliance baselines. The goal is to ensure your application adheres to the principle of least privilege and is resilient to common web-based attacks. In a typical scenario, a team might focus solely on application-level security (like input validation) while leaving the platform wide open through misconfigured CORS policies or outdated TLS settings. This checklist ensures the platform itself is a strong foundation for your secure code.

Authentication and Authorization (EasyAuth)

If using Azure App Service Authentication (EasyAuth), verify the identity provider (e.g., Azure AD, Microsoft Account) is correctly configured with the proper redirect URIs and application (client) IDs. Crucially, set "Action to take when request is not authenticated" to "Log in with [provider]", not "Allow Anonymous requests", unless your site has public areas. This ensures unauthenticated users are redirected to login before hitting your application code.

HTTPS-Only and Minimum TLS Version

Enable the "HTTPS Only" setting to force all HTTP traffic to HTTPS. Set the "Minimum TLS Version" to 1.2 (deprecating older, insecure versions like 1.0 and 1.1). This is a basic but critical control for data in transit. For maximum security, consider testing with TLS 1.3 as it becomes the standard.

Cross-Origin Resource Sharing (CORS)

Do not use the wildcard '*' for allowed origins in your CORS policy for production. Explicitly list the front-end application URLs that are permitted to access your API. An overly permissive CORS policy is a common misconfiguration that can expose your API to malicious sites.

SCM Site and FTP State

The SCM site (also known as the Kudu site) is a powerful management tool but also an attack surface. Restrict access to the SCM site using access restrictions or by disabling basic publishing credentials if you exclusively use deployment center or CI/CD. Consider if anonymous FTP deployment needs to be disabled entirely.

Platform and Framework Versions

Ensure the configured .NET, Java, Node.js, or PHP version is a current, supported version that receives security patches. Running outdated runtime versions is a severe security risk. Set the "Platform" to 64-bit for most modern applications unless you have a specific 32-bit dependency.

Diagnostic Logs and Retention

Enable Application Logging (Filesystem), Detailed Error Messages, and Failed Request Tracing for short-term debugging, but be mindful of logging personal data. For long-term security auditing, ensure "App Service logs" (specifically Web Server Logging) are enabled and streaming to a secure, access-controlled Log Analytics workspace or Storage Account with a defined retention policy.

Compliance and Regulatory Checks

If your industry is subject to regulations (like healthcare or finance), review the relevant compliance offerings. Azure Policy can help enforce standards like CIS benchmarks for App Service. As a manual check, review the "Diagnose and solve problems" blade for security-specific recommendations from Azure.

Secret Management Verification

Perform a final audit to ensure no passwords, API keys, or connection strings with plaintext credentials exist as App Settings. All must reference Key Vault secrets. Verify the Key Vault's network access policies (if using firewall) allow the App Service to connect, either via its outbound IP or, preferably, via Private Link.

Stage 3: Performance and Health Baseline

Deploying a functionally correct application that performs poorly is a failure. This stage is about establishing a performance and health baseline *before* users arrive. It involves configuring the observability tools that will let you understand your application's behavior under load and ensuring it has the resources it needs. Many teams wait until after launch to set up monitoring, which means they are flying blind during the most critical period. Here, we proactively configure logging, metrics, and alerts so you can detect issues the moment they arise, not when users start complaining. This turns your deployment from a black box into an instrumented system you can understand and manage.

Application Insights Integration

Integrate Azure Application Insights by ensuring the instrumentation key or connection string is correctly set as an application setting (preferably a slot setting). Verify custom telemetry (dependencies, traces, custom metrics) from your application code is flowing correctly. This is your primary window into application performance and user behavior.

Health Check Path Configuration

Configure the "Health check path" in the App Service settings to point to a lightweight endpoint in your application (e.g., /health). This allows the Azure load balancer to probe your instance's health and take unhealthy instances out of rotation, improving overall availability. Test this endpoint to ensure it returns a successful HTTP status code quickly.

Always On Setting

For any production App Service on a non-free tier, enable "Always On". This prevents the app from being unloaded after periods of inactivity, which causes a slow "cold start" for the first request after idle time. This is essential for consistent response times.

Auto-Scale Rules and Metrics

Review and enable your auto-scale rules based on metrics like CPU Percentage or Memory Percentage. Set reasonable thresholds (e.g., scale out at 70% avg CPU, scale in at 30%) and configure a sensible instance limit to control costs. Test the scale-out logic under load in a staging environment if possible.

Baseline Performance Metrics

Immediately after deployment to a staging slot, run a synthetic transaction or a light load test to capture baseline metrics: average response time for key pages, error rate, and dependencies (database calls, external APIs). Document these numbers. They become your reference point for detecting performance regression after the production swap or future deployments.

Alert Rule Configuration

Create essential alert rules in Azure Monitor *before* going live. Key alerts include: Failed requests rate > 5% over 5 minutes, Server response time > a threshold you define (e.g., 2 seconds), and HTTP 4xx/5xx status codes spiking. Route these alerts to your team's email, SMS, or collaboration tool (like Teams or Slack).

Logging Levels and Sampling

Adjust the logging verbosity in your application (e.g., from Information to Warning) for production to reduce noise and cost, but ensure critical errors and warnings are still captured. In Application Insights, configure adaptive sampling if you expect very high traffic to control ingestion costs while retaining representative data.

Dependency Health Check

Verify connectivity and performance to all external dependencies: databases, cache services, third-party APIs. Use a simple script or a test within your health endpoint to confirm they are reachable and responding within expected latency bounds from the App Service region.

Stage 4: Deployment Strategy and Execution Plan

How you deploy is as important as what you deploy. A poorly executed deployment can cause downtime, data corruption, or a confusing user experience. This stage focuses on selecting and validating your deployment strategy. Azure App Service offers several mechanisms, each with different trade-offs between complexity, risk, and downtime. We will compare the most common approaches to help you choose the right one for your application's tolerance for risk and change. Furthermore, we insist on having a concrete, step-by-step execution plan and a rollback plan that every team member understands. This transforms deployment from a hopeful click into a coordinated, reversible operation.

Comparing Deployment Strategies

Slot Swap Validation Checklist

If using slots (our recommended approach), run this sub-checklist before swapping: 1) Confirm all "slot setting" flags are correct. 2) Manually trigger the warm-up request to your health check path on the staging slot. 3) Perform a final smoke test on the staging slot using its temporary URL. 4) Ensure no long-running operations (like massive data jobs) are active on the production slot. 5) Communicate the maintenance window to stakeholders, even for a near-zero-downtime swap.

Rollback Plan Definition

Your deployment plan is incomplete without a rollback plan. For a slot swap, the rollback is simply swapping back. Document the exact trigger conditions for rollback (e.g., error rate > 10% for 2 minutes, critical feature broken) and who has the authority to execute it. The plan should be so clear that any on-call engineer can execute it under pressure.

Database Migration Strategy

If your deployment includes database schema changes, your strategy must account for this. Use backward-compatible migrations (e.g., add column nullable, deploy app, populate data, then make not nullable) to enable safe rollback of the application without breaking the database. Never deploy an app that requires a new non-nullable column before that column exists.

Execution Runbook

Create a step-by-step runbook for the person executing the deployment. It should include: 1) Pre-swap validation (run Stage 1-3 checks). 2) The exact Azure CLI/PowerShell/Portal click sequence for the swap. 3) Immediate post-swap validation steps (next section). 4) Rollback instructions. This eliminates ambiguity.

Communication and Stakeholder Alignment

Define what communication is needed, when, and to whom. This might include: an alert to the engineering team that deployment has started, a notification to support staff to be vigilant, and a status page update for customer-facing changes. Silence is not a strategy.

Timing and Traffic Considerations

Schedule the deployment during your application's lowest traffic period. Analyze your traffic patterns to identify this window. For globally distributed applications, remember that low traffic in one region may be peak in another.

Final Pre-Swap Smoke Test

In the staging slot, after the code is deployed, run an automated smoke test suite that exercises the key user journeys. This final gate gives you confidence that the deployment artifact itself is sound before it touches production traffic.

Stage 5: Immediate Post-Deployment Verification

The moment after deployment is the most critical monitoring period. Your pre-flight checks were predictions; now you gather evidence. This stage involves a rapid, structured verification that the application is functioning correctly under real production traffic. The goal is to confirm stability and catch any issues that slipped through the pre-flight net within minutes, not hours. We move from proactive checks to reactive observation, using the tools we set up in Stage 3. A common pitfall is declaring victory after a successful swap and walking away. Instead, you should enter a period of heightened vigilance, systematically checking key signals before considering the deployment fully complete.

Live Traffic and Error Rate Monitoring

Immediately open the Live Metrics stream in Application Insights. Watch for incoming requests and, crucially, for any exceptions or failures. A spike in errors is the most urgent signal. Compare the current error rate to your pre-deployment baseline.

Health Check Endpoint Verification

Manually and programmatically hit your configured health check path from outside the Azure network (simulating a user) to ensure it returns a healthy status. Also, verify the Azure infrastructure is probing it successfully by checking the App Service health check blade.

Dependency Performance Check

In Application Insights, view the "Performance" blade and examine the dependency calls (SQL, HTTP, etc.). Look for a sudden increase in duration or failure rate compared to your baseline. A slow database call chain is a common post-deployment issue.

Business Transaction Verification

Execute a few key business transactions as a real user would. For an e-commerce site, this might mean browsing a product, adding to cart, and initiating checkout (stopping before payment). This tests the integrated flow, not just isolated endpoints.

Configuration and Feature Flag Validation

Verify that any new configuration values or feature flags deployed are taking effect correctly. This might involve checking that a new API endpoint is active or that a specific UI feature is visible/enabled based on the configuration.

Alert Rule Silence Check

Monitor your alerting channels. Ironically, a lack of expected alerts can be a problem—ensure your alert rules are firing correctly by checking that you receive a test alert. Also, watch for any new, unexpected alerts that trigger.

Capacity and Resource Utilization

Monitor the App Service metrics in the Azure portal for the first 15-30 minutes: CPU, Memory, and HTTP Queue length. Ensure they are within normal bounds and not trending upward dangerously, which could indicate a memory leak or inefficient code path.

Declaring Stability and Handing Over

Define a clear criterion for when the deployment is considered "stable." This could be "5 minutes with error rate below 0.1%" or "successful completion of all smoke test transactions." Once met, communicate to the team that the deployment is complete and hand over to routine monitoring. Document any observed anomalies for future retrospective analysis.

Common Questions and Troubleshooting Scenarios

Even with a thorough checklist, things can go wrong. This section addresses frequent questions and provides a diagnostic framework for common post-deployment failure modes. The focus is on practical, immediate steps to triage issues. We avoid theoretical explanations in favor of actionable guidance that helps you restore service quickly. Remember, the goal of the pre-flight checklist is to minimize the need for this section, but being prepared for it is equally important.

"The site is up but painfully slow. What do I check first?"

First, check App Service metrics for high CPU or Memory, which could trigger throttling. Then, go to Application Insights "Performance" to identify the slowest operations. Common culprits are N+1 database queries introduced with new code, un-cached dependencies, or an under-sized App Service Plan SKU. Compare to your pre-deployment baseline.

"My app deployed, but it's showing the default App Service page."

This usually means the deployment didn't place files in the correct location or the virtual path/application settings are wrong. Verify the deployment method (e.g., ZIP deploy expects the .zip at the site root). Check the "Path mapping" (Virtual applications and directories) in the Configuration section to ensure the virtual path is set to "/" and points to site\wwwroot.

"I'm getting a 'Could not connect to database' error after swap."

This is almost always a configuration issue. 1) Verify the connection string application setting was marked as a "slot setting" so it didn't swap. 2) Check the exact value matches the production database. 3) Ensure the database firewall allows the *new* outbound IPs of the App Service (post-swap, the outbound IPs may differ if you swapped slots).

"Health check is failing, causing my instances to cycle."

First, access the SCM site (https://<yoursite>.scm.azurewebsites.net) and browse the logs to see if the health endpoint is throwing an exception. The health check must complete very quickly (<10 seconds is a good target) and should not require authentication. Ensure it doesn't have dependencies that are themselves unhealthy.

"My custom domain isn't working after deployment."

Check the TLS/SSL binding in the App Service. Sometimes the binding is lost during operations. Re-bind the certificate. Also, verify DNS propagation using a tool like dig or nslookup from outside Azure. Remember, DNS changes can take up to 48 hours to propagate globally, though usually it's faster.

"How do I roll back quickly if something is wrong?"

If you used slot swap, immediately swap back to the previous slot. This is your primary rollback. If you deployed directly, you need to redeploy the previous known-good package. This is why direct deploy is not recommended. Always have the previous deployment artifact readily available.

"Application Insights is showing no data after deployment."

Verify the APPLICATIONINSIGHTS_CONNECTION_STRING or instrumentation key is correctly set as an application setting and is a "slot setting" if you use slots. Check for any IP firewall rules on the Application Insights resource that might be blocking traffic from Azure's data centers. Also, verify your app's SDK configuration.

"When should I scale up my App Service Plan vs. scaling out?"

Scale up (to a higher SKU, e.g., P1v3 to P2v3) for applications that are single-instance due to statefulness or when you need more memory/CPU per instance. Scale out (add more instances) for stateless applications to handle more concurrent users and improve availability. Use auto-scale rules for variable load, but scale up manually for consistent baseline load increases.

Conclusion: Building a Culture of Reliable Deployment

Adopting this pre-flight checklist is more than a technical exercise; it's a step towards building a culture of reliability and operational excellence. By systematically addressing environment, security, performance, strategy, and verification, you transform deployment from a point of anxiety into a predictable, controlled process. The real value accrues over time as these practices become habit, reducing fire drills, increasing team confidence, and improving the experience for your end-users. Remember, this checklist is a starting point. Tailor it to your organization's specific needs, integrate it into your automation, and review it periodically as Azure services and your application evolve. The goal is not perfection, but relentless improvement in your path to production. Start with your next deployment: pick one section of this guide, implement it fully, and observe the difference it makes. Consistent, small improvements in process lead to dramatically better outcomes over the long run.

Key Takeaways for Busy Teams

1. Validate configurations systematically, never assume. 2. Security hardening is a prerequisite, not an afterthought. 3. Establish observability *before* you need it. 4. Choose a deployment strategy that matches your risk tolerance—slots are your friend. 5. Watch like a hawk immediately after going live. 6. Always have a rollback plan.

Next Steps and Continuous Improvement

After a few deployments using this framework, hold a brief retrospective. What checks caught issues? What issues slipped through? Update your checklist accordingly. Consider automating more checks using Azure CLI scripts or integrating validation tasks into your CI/CD pipeline as gates. Share the checklist with new team members to onboard them into your deployment culture.

Final Thought

In cloud operations, the price of reliability is eternal vigilance—but that vigilance is best structured, not frantic. This checklist provides that structure. By investing time in the pre-flight, you save immeasurable time, stress, and reputation post-flight. Deploy with confidence.