In today’s world of modern DevOps and continuous delivery, having the ability to analyze application behavior quickly and efficiently is key to Quality Assurance (QA). Azure Application Insights offers powerful telemetry collection, but what makes it truly shine is the Kusto Query Language (KQL)—a rich, expressive query language that enables deep-dive analytics into your application’s performance, usage, and errors. Whether you’re testing a web app, monitoring API failures, or validating load test results, KQL can become your best QA companion. What is KQL? KQL stands for Kusto Query Language, and it’s used to query telemetry data collected by Azure Monitor, Application Insights, and Log Analytics. It’s designed to be read like English, with SQL-style expressions, yet much more powerful for telemetry analysis. Challenges Faced with Application Insights in QA 1. Telemetry data doesn’t always show up immediately after execution, causing delays in debugging and test validation. 2.When testing involves thousands of records, isolating failed requests or exceptions becomes tedious and time-consuming. 3.The default portal experience lacks intuitive filters for QA-specific needs like test case IDs, custom payloads, or user roles. 4.Repeated logs from expected failures (e.g., negative test cases) can clutter insights, making it hard to focus on actual issues. 5.Out-of-the-box telemetry doesn’t group actions by test scenario or user session unless explicitly configured, making traceability difficult during test case validation. To overcome these limitations, QA teams need more than just default dashboards—they need flexibility, precision, and speed in analyzing telemetry. This is where Kusto Query Language (KQL) becomes invaluable. With KQL, testers can write custom queries to filter, group, and visualize telemetry exactly the way they need, allowing them to focus on real issues, validate test scenarios, and make data-driven decisions faster and more efficiently. Let’s take some examples for better understanding: Some Common scenarios where a KQL proves to be very effective. Check if the latest deployment introduced new exceptions Example: Find all failed requests Example: Analyse performance of a specific page or operation Example: Correlate request with exceptions Example: Validate custom event tracking (like button clicks) Example: Track specific user sessions for end-to-end QA testing Example: Test API performance under load Example: All of this can be Visualized too – You can pin your KQL queries to Azure Dashboards or even Power BI for real-time tracking during QA sprints. To conclude, KQL is not just for developers or DevOps. QA engineers can significantly reduce manual log-hunting and accelerate issue detection by writing powerful queries in Application Insights. By incorporating KQL into your testing lifecycle, you add an analytical edge to your QA process—making quality not just a gate but a continuous insight loop.Start with a few basic queries, and soon you’ll be building powerful dashboards that QA, Dev, and Product can all share! Hope this helps ! I hope you found this blog useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfronts.com.

When deploying applications on Azure App Service, certain environment variables play a pivotal role in ensuring smooth operation and efficient resource management. One such variable is WEBSITE_CONTENTSHARE. In this blog, we will explore what WEBSITE_CONTENTSHARE is, why it matters, and how you can work with it effectively. What is WEBSITE_CONTENTSHARE? The WEBSITE_CONTENTSHARE environment variable is a unique identifier automatically generated by Azure App Service. It specifies the name of the Azure Storage file share used by an App Service instance when its content is deployed to an Azure App Service plan using shared storage, such as in a Linux or Windows containerized environment. This variable is particularly relevant for scenarios where application code and content are stored and accessed from a shared file system. It ensures that all App Service instances within a given plan have consistent access to the application’s files. Key Use Cases How WEBSITE_CONTENTSHARE Works When you deploy an application to Azure App Service: Example Value: This value points to a file share named app-content-share1234 in the configured Azure Storage account. Configuring WEBSITE_CONTENTSHARE While the WEBSITE_CONTENTSHARE variable is automatically managed by Azure, there are instances where you may need to adjust configurations: Troubleshooting Common Issues 1. App Service Cannot Access File Share 2. Variable Not Set 3. File Share Quota Exceeded Best Practices To conclude that, The WEBSITE_CONTENTSHARE variable is a crucial part of Azure App Service’s infrastructure, facilitating shared storage access for applications. By understanding its purpose, configuration, and best practices, you can ensure your applications leverage this feature effectively and run seamlessly in Azure’s cloud environment. We hope you found this blog useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfonts.com.