Announcing Database connections for Azure Static Web Apps with Data API builder
With database connections for Azure Static Web Apps, you can access your Azure database contents directly from your static site, without having to write any backend code. Build your applications faster, while ensuring security and serverless scalability. Free during public preview.From Local MCP Server to Hosted Web Agent: App Service Observability, Part 2
In Part 1, we introduced the App Service Observability MCP Server — a proof-of-concept that lets GitHub Copilot (and other AI assistants) query your App Service logs, analyze errors, and help debug issues through natural language. That version runs locally alongside your IDE, and it's great for individual developers who want to investigate their apps without leaving VS Code. A local MCP server is powerful, but it's personal. Your teammate has to clone the repo, configure their IDE, and run it themselves. What if your on-call engineer could just open a browser and start asking questions? What if your whole team had a shared observability assistant — no setup required? In this post, we'll show how we took the same set of MCP tools and wrapped them in a hosted web application — deployed to Azure App Service with a chat UI and a built-in Azure OpenAI agent. We'll cover what changed, what stayed the same, and why this pattern opens the door to far more than just a web app. Quick Recap: The Local MCP Server If you haven't read Part 1, here's the short version: We built an MCP (Model Context Protocol) server that exposes ~15 observability tools for App Service — things like querying Log Analytics, fetching Kudu container logs, analyzing HTTP errors, correlating deployments with failures, and checking logging configurations. You point your AI assistant (GitHub Copilot, Claude, etc.) at the server, and it calls those tools on your behalf to answer questions about your apps. That version: Runs locally on your machine via node Uses stdio transport (your IDE spawns the process) Relies on your Azure credentials ( az login ) — the AI operates with your exact permissions Requires no additional Azure resources It works. It's fast. And for a developer investigating their own apps, it's the simplest path. This is still a perfectly valid way to use the project — nothing about the hosted version replaces it. The Problem: Sharing Is Hard The local MCP server has a limitation: it's tied to one developer's machine and IDE. In practice, this means: On-call engineers need to clone the repo and configure their environment before they can use it Team leads can't point someone at a URL and say "go investigate" Non-IDE users (PMs, support engineers) are left out entirely Consistent configuration (which subscription, which resource group) has to be managed per-person We wanted to keep the same tools and the same observability capabilities, but make them accessible to anyone with a browser. The Solution: Host It on App Service The answer turned out to be straightforward: deploy the MCP server itself to Azure App Service, give it a web frontend, and bring its own AI agent along for the ride. Here's what the hosted version adds on top of the local MCP server: Local MCP Server Hosted Web Agent How it works Runs locally, your IDE's AI calls the tools Deployed to Azure App Service with its own AI agent Interface VS Code, Claude Desktop, or any MCP client Browser-based chat UI Agent Your existing AI assistant (Copilot, Claude, etc.) Built-in Azure OpenAI (GPT-5-mini) Azure resources needed None beyond az login App Service, Azure OpenAI, VNet Best for Individual developers in their IDE Teams who want a shared, centralized tool Authentication Your local az login credentials Managed identity + Easy Auth (Entra ID) Deploy npm install && npm run build azd up The key insight: the MCP tools are identical. Both versions use the exact same set of observability tools — the only difference is who's calling them (your IDE's AI vs. the built-in Azure OpenAI agent) and where the server runs (your laptop vs. App Service). What We Built Architecture ┌─────────────────────────────────────────────────────────────────────────────┐ │ Web Browser │ │ React Chat UI — resource selectors, tool steps, markdown responses │ └──────────────────────────────────┬──────────────────────────────────────────┘ │ HTTP (REST API) ▼ ┌─────────────────────────────────────────────────────────────────────────────┐ │ Azure App Service (Node.js 20) │ │ ┌──────────────────────────────────────────────────────────────────────┐ │ │ │ Express Server │ │ │ │ ├── /api/chat → Agent loop (OpenAI → tool calls → respond) │ │ │ │ ├── /api/set-context → Set target app for investigation │ │ │ │ ├── /api/resource-groups, /api/apps → Resource discovery │ │ │ │ ├── /mcp → MCP protocol endpoint (Streamable HTTP) │ │ │ │ └── / → Static SPA (React chat UI) │ │ │ └──────────────────────────────────────────────────────────────────────┘ │ │ VNet Integration (snet-app) │ └─────────────────────────────────────────────────────────────────────────────┘ │ │ │ ▼ ▼ ▼ ┌──────────────┐ ┌───────────────────┐ ┌────────────────────┐ │ Azure OpenAI │ │ Log Analytics / │ │ ARM API / Kudu │ │ (GPT-5-mini) │ │ KQL Queries │ │ (app metadata, │ │ Private EP │ └───────────────────┘ │ container logs) │ └──────────────┘ └────────────────────┘ The Express server does double duty: it serves the React chat UI as static files and exposes the MCP endpoint for remote IDE connections. The agent loop is simple — when a user sends a message, the server calls Azure OpenAI, which may request tool calls, the server executes those tools, and the loop continues until the AI has a final answer. Demo The following screenshots show how this app can be used. The first screenshot shows what happens when you ask about a functioning app. You can see the agent made 5 tool calls and was able to give a thorough summary of the current app's status, recent deployments, as well as provide some recommendations for how to improve observability of the app itself. I expanded the tools section so you could see exactly what the agent was doing behind the scenes and get a sense of how it was thinking. At this point, you can proceed to ask more questions about your app if there were other pieces of information you wanted to pull from your logs. I then injected a fault into this app by initiating a deployment pointing to a config file that didn't actually exist. The goal here was to prove that the agent could correlate an application issue to a specific deployment event, something that currently involves manual effort and deep investigation into logs and source code. Having an agent that can do this for you in a matter of seconds saves so much time and effort that could be directed to more important activities and ensures that you find the issue the first time. A few minutes after initiating the bad deployment, I saw that my app was no longer responding. Rather than going to the logs and investigating myself, I asked the agent "I'm getting an application error now, what happened?" I obviously know what happened and what the source of the error was, but let's see if the agent can pick that up. The agent was able to see that something was wrong and then point me in the direction to address the issue. It ran a number of tool calls following our investigation steps called out in the skills file and was successfully able to identify the source of the error. And lastly, I wanted to confirm the error was associated with the recent deployment, something that our agent should be able to do because we built in the tools it needs to be able to corrleate these kinds of events with errors. I asked it directly and here was the response, exactly what I expected to see. Infrastructure (one command) Everything is defined in Bicep and deployed with the Azure Developer CLI: azd up This provisions: App Service Plan (P0v3) with App Service (Node.js 20 LTS, VNet-integrated) Azure OpenAI (GPT-5-mini, Global Standard) with a private endpoint and private DNS zone VNet (10.0.0.0/16) with dedicated subnets for the app and private endpoints Managed Identity with RBAC roles: Reader, Website Contributor, Log Analytics Reader, Cognitive Services OpenAI User No API keys anywhere. The App Service authenticates to Azure OpenAI over a private network using its managed identity. The Chat UI The web interface is designed to get out of the way and let you focus on investigating: Resource group and app dropdowns — Browse your subscription, pick the app you want to investigate Tool step visibility — A collapsible panel shows exactly which tools the agent called, what arguments it used, and how long each took Session management — Start fresh conversations, with confirmation dialogs when switching context mid-investigation Markdown responses — The agent's answers are rendered with full formatting, code blocks, and tables When you first open the app, it auto-discovers your subscription and populates the resource group dropdown. Select an app, hit "Tell me about this app," and the agent starts investigating. Security Since this app has subscription-wide read access to your App Services and Log Analytics workspaces, you should definitely enable authentication. After deploying, configure Easy Auth in the Azure Portal: Go to your App Service → Authentication Click Add identity provider → select Microsoft Entra ID Set Unauthenticated requests to "HTTP 401 Unauthorized" This ensures only authorized members of your organization can access the tool. The connection to Azure OpenAI is secured via a private endpoint — traffic never traverses the public internet. The app authenticates using its managed identity with the Cognitive Services OpenAI User role. What Stayed the Same This is the part worth emphasizing: the core tools didn't change at all. Whether you're using the local MCP server or the hosted web agent, you get the same 15 tools. The Agent Skill (SKILL.md) from Part 1 also carries over. The hosted agent has the same domain expertise for App Service debugging baked into its system prompt — the same debugging workflows, common error patterns, KQL templates, and SKU reference that make the local version effective. The Bigger Picture: It's Not Just a Web App Here's what makes this interesting beyond our specific implementation: the pattern is the point. We took a set of domain-specific tools (App Service observability), wrapped them in a standard protocol (MCP), and showed two ways to use them: Local MCP server → Your IDE's AI calls the tools Hosted web agent → A deployed app with its own AI calls the same tools But those are just two examples. The same tools could power: A Microsoft Teams bot — Your on-call channel gets an observability assistant that anyone can mention A Slack integration — Same idea, different platform A CLI agent — A terminal-based chat for engineers who live in the command line An automated monitor — An agent that periodically checks your apps and files alerts An Azure Portal extension — Observability chat embedded directly in the portal experience A mobile app — Check on your apps from your phone during an incident The MCP tools are the foundation. The agent and interface are just the delivery mechanism. Build whatever surface makes sense for your team. This is one of the core ideas behind MCP: write the tools once, use them everywhere. The protocol standardizes how AI assistants discover and call tools, so you're not locked into any single client or agent. Try It Yourself Both versions are open-source: Local MCP server (Part 1): github.com/seligj95/app-service-observability-agent Hosted web agent (Part 2): github.com/seligj95/app-service-observability-agent-hosted To deploy the hosted version: git clone https://github.com/seligj95/app-service-observability-agent-hosted.git cd app-service-observability-agent-hosted azd up To run the local version, see the Getting Started section in Part 1. What's Next? This is still a proof-of-concept, and we're continuing to explore how AI-powered observability can become a first-class part of the App Service platform. Some things we're thinking about: More tools — Resource health, autoscale history, certificate expiration, network diagnostics Multi-app investigations — Correlate issues across multiple apps in a resource group Proactive monitoring — Agents that watch your apps and alert you before users notice Deeper integration — What if every App Service came with a built-in observability endpoint? We'd love your feedback. Try it out, open an issue, or submit a PR if you have ideas for additional tools or debugging patterns. And if you build something interesting on top of these MCP tools — a Teams bot, a CLI agent, anything — we'd love to hear about it.Strapi on App Service: Quick start
In this quick start guide, you will learn how to create and deploy your first Strapi site on Azure App Service Linux, using Azure Database for MySQL or PostgreSQL, along with other necessary Azure resources. This guide utilizes an ARM template to install the required resources for hosting your Strapi application.Chat with Your App Service Logs Using GitHub Copilot
The Problem We know that logs and observability on App Service can be tricky—it's feedback we hear from customers all the time. There are many sources of information: Kudu container logs, Log Analytics tables (AppServiceHTTPLogs, ConsoleLogs, PlatformLogs, AppLogs), deployment logs, metrics, and more. It's not always obvious where to look, especially when you're troubleshooting under pressure. Today, debugging production issues often involves: Opening the Azure Portal Figuring out which blade or log source has the information you need Navigating to Log Analytics and remembering (or searching for) the right KQL syntax Interpreting results and manually correlating across multiple log tables Repeating this process until you find the root cause This proof-of-concept is one of our attempts to simplify this experience, using AI to bridge the gap between your question and the answer—no matter where that answer lives. What if you could just ask: "Why did my app stop?" and get an answer without ever having to leave your IDE or terminal? The Solution: App Service Observability MCP Server We've built a proof-of-concept MCP (Model Context Protocol) server that exposes App Service observability tools directly to AI assistants like GitHub Copilot in VS Code. It can be accessed from your preferred IDE like VS Code, or directly in your CLI such as GitHub Copilot CLI or Claude Code. You now don't even have to leave your coding environment to get answers to your App Service issues. Key capabilities: Query logs from Log Analytics (HTTP logs, Console logs, Platform logs) Fetch container logs directly from Kudu (no setup required!) Analyze HTTP errors grouped by status code and endpoint Find slow requests exceeding latency thresholds Diagnose deployment issues — automatically correlate deploys with startup failures and errors Check logging setup — runtime-specific recommendations (Python, Node.js, .NET, Java) View deployment history and correlate with issues Investigate container restarts and identify root causes Demo To see how the tool works, here are a series of screenshots going over a real-world scenario where a deployment issue breaks an app. The first screenshot is from when the app was functioning with no issues. You can see the tool calls one of MCP tools to get the app info. I then asked if there were any issues. It found a couple issues early on, but they were all transient and after reviewing logs and errors, it determined the app was functional. I then introduced a bug into my app and redeployed. I changed the name of a reference to a config file to one that didn't exist, thereby causing the app to crash because it was trying to load a file that didn't exist. GitHub Copilot was easily able to pick up the issue based on the deployment logs tooling. Also, because GitHub Copliot has direct access to my codebase for the app it was analyzing, it was able to see that the file that I was referencing didn't exist and knew what to change it to to get the app working again. This is one of the benefits of running this tool locally alongside your codebase - in addition to the tooling, it can also keep an eye on your codebase. Now if you've ever used GitHub Copilot to help deploy one of your apps, you may know that it can natively make calls using the Azure CLI for example to pull logs. But in my experience, these actions don't always work, take multiple attempts, and take a significant amount of time to complete. With the tooling and skills here, this operation becomes seamless because the agent knows exactly what to do and how to do it. It takes away the guesswork and multiple attempts that an agent without this tool would have to go through. In the following screenshot, I asked why the deployment was taking so long. Usually a deployment with azd for an app like the demo app here takes under a minute, so I wanted it to help me understand what the delay was caused by. Within a couple seconds, it was able to pickup the bug I introduced. Lastly, I then asked it to correlate the error with a deployment. One of the major problem areas our customers have is determining which deployment led to a specific error. We've built a tool into this feature that can correlate deployements and errors. Here's what the tool found. You can see I did a couple deployments with config file names that didn't exist. The tool was able to pinpoint the exact deployments that caused the issue and also tell me what to change to remediate the issue. This is a major benefit that was only possible with the help of AI and it's reasoning capabilities. How It Works The MCP server sits between your AI assistant and Azure, translating natural language requests into API calls: Important: Some tools require Log Analytics diagnostic settings to be enabled, but `get_recent_logs` and `get_deployments` work out of the box by calling Kudu and ARM directly. Security: Your Credentials, Your Access A common question when connecting AI tools to cloud resources: "What access does this have?" The MCP server here uses `DefaultAzureCredential` from the Azure SDK, which means it leverages your existing Azure identity—typically from `az login`. It can only access resources you already have permission to access. There are no stored secrets, no service principals with elevated privileges, and no additional credentials required. In other words: if you could run the investigation yourself in the portal or via Azure CLI, the MCP server can do it. If you don't have access to a resource, neither does the server. This design ensures: No privilege escalation — The AI operates with your exact permissions Existing RBAC applies — Your organization's access controls are respected Audit trail intact — All API calls use your identity and appear in Azure activity logs Looking ahead: For production scenarios with fully autonomous agents (running unattended or on a schedule), you'd want to apply least-privilege principles—create a dedicated service principal or managed identity with only the specific permissions needed (e.g., Reader on the App Service, Log Analytics Reader on the workspace). This limits blast radius and follows security best practices for any automated system accessing cloud resources. The Agent Skill: Domain Expertise for Debugging Beyond just exposing tools, we've included an Agent Skill file (SKILL.md) that gives the AI domain expertise for App Service debugging. What's an Agent Skill? Agent Skills are markdown files that provide structured knowledge to AI assistants. When GitHub Copilot has access to our SKILL.md, it gains: Debugging workflows — Step-by-step approaches for investigating issues Common error patterns — OOM crashes, Always On issues, HTTP 500/503 errors KQL query templates — Ready-to-use queries for each scenario SKU reference — Which features are available on each pricing tier Best practices — How to present findings with actionable recommendations Tools + Knowledge = Better Debugging The MCP tools and Agent Skill work together: Component Role MCP Tools Fetch real data from your Azure resources Agent Skill Interpret results and guide investigations For example, when investigating a container restart, the Agent Skill teaches Copilot to: Check for OOM patterns in platform logs Look for crash loops vs. graceful terminations Consider Always On settings based on the SKU Provide the right `az` command to fix the issue Example: Investigating a Container Stop Here's a real conversation showing AI-assisted debugging: User: "Show me the recent logs" Copilot: calls get_recent_logs 2026-01-30T19:52:42Z Container start method called. 2026-01-30T19:52:43Z Container is running. 2026-01-30T19:52:57Z Site started. 2026-01-30T19:53:17Z Container is terminating. Grace period: 5 seconds. 2026-01-30T19:53:22Z Site stopped. Copilot: The site started but stopped after 20 seconds. Want me to investigate? User: "Please investigate" Copilot: calls check_diagnostics, get_http_errors, query_logs, get_app_info Root Cause: Your container is stopping because "Always On" is disabled. With low traffic (only 14 requests in 24 hours), App Service terminates idle containers to save resources. Evidence: ✅ No errors in platform or application logs ✅ No HTTP 5xx errors Container terminated gracefully (not a crash) Fix: az webapp config set --name your-app --resource-group your-rg --always-on true Note: Requires Basic tier or higher. No portal. No manual KQL. Just ask and get answers. Getting Started Prerequisites Node.js 20+ Azure CLI (`az login` for authentication) VS Code with GitHub Copilot Installation git clone https://github.com/seligj95/app-service-observability-agent.git cd app-service-observability-agent npm install && npm run build Configure VS Code Create `.vscode/mcp.json` in your workspace: { "servers": { "appservice-logs": { "command": "node", "args": ["/path/to/app-service-observability-agent/dist/index.js"], "type": "stdio", "env": { "AZURE_SUBSCRIPTION_ID": "your-subscription-id", "AZURE_RESOURCE_GROUP": "your-resource-group", "AZURE_APP_NAME": "your-app-name" } } } } Reload VS Code, click "Start" next to the server, and start chatting with Copilot about your App Service! What's Next? This is a proof-of-concept demonstrating what an App Service AI observability tool could look like. We're exploring how this pattern could become a first-class feature of the platform. Imagine a future where every App Service has a built-in MCP endpoint for observability: https://my-app.scm.azurewebsites.net/mcp. Stay tuned for part 2 of this blog where we will show how to host this tool on App Service so that not just you, but you're whole team can leverage this tool for your workloads. Try It Out GitHub Repo: github.com/seligj95/app-service-observability-agent Agent Skill: Check out SKILL.md for the debugging knowledge base We'd love your feedback! Use the comments below or open an issue or PR if you have ideas for additional tools or debugging patterns.
Announcing Conversational Diagnostics (Preview) on Windows App Services
We are pleased to announce Conversational Diagnostics (Preview), a new feature in Windows App Services that leverages the powerful capabilities of OpenAI to take your problem-solving to the next level. With this feature, you can engage in a conversational dialogue to accurately identify the issue with your Windows Web Apps, and receive a clear set of solutions, documentation, and diagnostics to help resolve the issue. How to access Conversational Diagnostics (Preview) Navigate to your Windows Web App on the Azure Portal. Select Diagnose and Solve Problems. Select AI Powered Diagnostics (preview) to open chat. What is the tool capable of? Type a question or select any of the sample questions in the options. Types of questions you can ask include but not limited to: Questions regarding a specific issue that your app is experiencing Questions about how-to instructions Questions about best practices The AI-powered Diagnostics runs relevant diagnostic checks and provides a diagnosis of the issue and a recommended solution. Additionally, it can provide documentation addressing your questions. Select View Details for a deep-dive view on the solution and reference to the suggested insight. Launch recommended solutions directly from the chat. Conversational Diagnostics (Preview) remembers the context of the conversation, so you can ask follow-up questions. Once you are done with troubleshooting, you can create a summary of your troubleshooting session by responding to the chat with the message that the issue has been resolved. If you want to start a new investigation, select New Chat. How to sign up for access To get started, sign up for early access to the Conversational Diagnostics (Preview) feature in the Diagnose and Solve Problems experience. Your access request may take up to 4 weeks to complete. Once access is granted, Conversational Diagnostics (Preview) will be available for all the Windows App Service on your subscription. Navigate to your Windows Web App on the Azure Portal. Select Diagnose and Solve Problems. Select Request Access in the announcement banner. Whether you're a seasoned developer or a newcomer to App Services, Conversational Diagnostics (Preview) provides an intuitive and efficient way to understand and tackle any issue you may encounter. You can easily access this feature whenever you need it without any extra configuration. Say goodbye to frustrating troubleshooting and hello to a smarter, more efficient way of resolving issues with App Services. Preview Terms Of Use | Microsoft Azure Microsoft Privacy Statement – Microsoft privacyBeyond the Desktop: The Future of Development with Microsoft Dev Box and GitHub Codespaces
The modern developer platform has already moved past the desktop. We’re no longer defined by what’s installed on our laptops, instead we look at what tooling we can use to move from idea to production. An organisations developer platform strategy is no longer a nice to have, it sets the ceiling for what’s possible, an organisation can’t iterate it's way to developer nirvana if the foundation itself is brittle. A great developer platform shrinks TTFC (time to first commit), accelerates release velocity, and maybe most importantly, helps alleviate everyday frictions that lead to developer burnout. Very few platforms deliver everything an organization needs from a developer platform in one product. Modern development spans multiple dimensions, local tooling, cloud infrastructure, compliance, security, cross-platform builds, collaboration, and rapid onboarding. The options organizations face are then to either compromise on one or more of these areas or force developers into rigid environments that slow productivity and innovation. This is where Microsoft Dev Box and GitHub Codespaces come into play. On their own, each addresses critical parts of the modern developer platform: Microsoft Dev Box provides a full, managed cloud workstation. Dev Box gives developers a consistent, high-performance environment while letting central IT apply strict governance and control. Internally at Microsoft, we estimate that usage of Dev Box by our development teams delivers savings of 156 hours per year per developer purely on local environment setup and upkeep. We have also seen significant gains in other key SPACE metrics reducing context-switching friction and improving build/test cycles. Although the benefits of Dev Box are clear in the results demonstrated by our customers it is not without its challenges. The biggest challenge often faced by Dev Box customers is its lack of native Linux support. At the time of writing and for the foreseeable future Dev Box does not support native Linux developer workstations. While WSL2 provides partial parity, I know from my own engineering projects it still does not deliver the full experience. This is where GitHub Codespaces comes into this story. GitHub Codespaces delivers instant, Linux-native environments spun up directly from your repository. It’s lightweight, reproducible, and ephemeral ideal for rapid iteration, PR testing, and cross-platform development where you need Linux parity or containerized workflows. Unlike Dev Box, Codespaces can run fully in Linux, giving developers access to native tools, scripts, and runtimes without workarounds. It also removes much of the friction around onboarding: a new developer can open a repository and be coding in minutes, with the exact environment defined by the project’s devcontainer.json. That said, Codespaces isn’t a complete replacement for a full workstation. While it’s perfect for isolated project work or ephemeral testing, it doesn’t provide the persistent, policy-controlled environment that enterprise teams often require for heavier workloads or complex toolchains. Used together, they fill the gaps that neither can cover alone: Dev Box gives the enterprise-grade foundation, while Codespaces provides the agile, cross-platform sandbox. For organizations, this pairing sets a higher ceiling for developer productivity, delivering a truly hybrid, agile and well governed developer platform. Better Together: Dev Box and GitHub Codespaces in action Together, Microsoft Dev Box and GitHub Codespaces deliver a hybrid developer platform that combines consistency, speed, and flexibility. Teams can spin up full, policy-compliant Dev Box workstations preloaded with enterprise tooling, IDEs, and local testing infrastructure, while Codespaces provides ephemeral, Linux-native environments tailored to each project. One of my favourite use cases is having local testing setups like a Docker Swarm cluster, ready to go in either Dev Box or Codespaces. New developers can jump in and start running services or testing microservices immediately, without spending hours on environment setup. Anecdotally, my time to first commit and time to delivering “impact” has been significantly faster on projects where one or both technologies provide local development services out of the box. Switching between Dev Boxes and Codespaces is seamless every environment keeps its own libraries, extensions, and settings intact, so developers can jump between projects without reconfiguring or breaking dependencies. The result is a turnkey, ready-to-code experience that maximizes productivity, reduces friction, and lets teams focus entirely on building, testing, and shipping software. To showcase this value, I thought I would walk through an example scenario. In this scenario I want to simulate a typical modern developer workflow. Let's look at a day in the life of a developer on this hybrid platform building an IOT project using Python and React. Spin up a ready-to-go workstation (Dev Box) for Windows development and heavy builds. Launch a Linux-native Codespace for cross-platform services, ephemeral testing, and PR work. Run "local" testing like a Docker Swarm cluster, database, and message queue ready to go out-of-the-box. Switch seamlessly between environments without losing project-specific configurations, libraries, or extensions. 9:00 AM – Morning Kickoff on Dev Box I start my day on my Microsoft Dev Box, which gives me a fully-configured Windows environment with VS Code, design tools, and Azure integrations. I select my teams project, and the environment is pre-configured for me through the Dev Box catalogue. Fortunately for me, its already provisioned. I could always self service another one using the "New Dev Box" button if I wanted too. I'll connect through the browser but I could use the desktop app too if I wanted to. My Tasks are: Prototype a new dashboard widget for monitoring IoT device temperature. Use GUI-based tools to tweak the UI and preview changes live. Review my Visio Architecture. Join my morning stand up. Write documentation notes and plan API interactions for the backend. In a flash, I have access to my modern work tooling like Teams, I have this projects files already preloaded and all my peripherals are working without additional setup. Only down side was that I did seem to be the only person on my stand up this morning? Why Dev Box first: GUI-heavy tasks are fast and responsive. Dev Box’s environment allows me to use a full desktop. Great for early-stage design, planning, and visual work. Enterprise Apps are ready for me to use out of the box (P.S. It also supports my multi-monitor setup). I use my Dev Box to make a very complicated change to my IoT dashboard. Changing the title from "IoT Dashboard" to "Owain's IoT Dashboard". I preview this change in a browser live. (Time for a coffee after this hardwork). The rest of the dashboard isnt loading as my backend isnt running... yet. 10:30 AM – Switching to Linux Codespaces Once the UI is ready, I push the code to GitHub and spin up a Linux-native GitHub Codespace for backend development. Tasks: Implement FastAPI endpoints to support the new IoT feature. Run the service on my Codespace and debug any errors. Why Codespaces now: Linux-native tools ensure compatibility with the production server. Docker and containerized testing run natively, avoiding WSL translation overhead. The environment is fully reproducible across any device I log in from. 12:30 PM – Midday Testing & Sync I toggle between Dev Box and Codespaces to test and validate the integration. I do this in my Dev Box Edge browser viewing my codespace (I use my Codespace in a browser through this demo to highlight the difference in environments. In reality I would leverage the VSCode "Remote Explorer" extension and its GitHub Codespace integration to use my Codespace from within my own desktop VSCode but that is personal preference) and I use the same browser to view my frontend preview. I update the environment variable for my frontend that is running locally in my Dev Box and point it at the port running my API locally on my Codespace. In this case it was a web socket connection and HTTPS calls to port 8000. I can make this public by changing the port visibility in my Codespace. https://fluffy-invention-5x5wp656g4xcp6x9-8000.app.github.dev/api/devices wss://fluffy-invention-5x5wp656g4xcp6x9-8000.app.github.dev/ws This allows me to: Preview the frontend widget on Dev Box, connecting to the backend running in Codespaces. Make small frontend adjustments in Dev Box while monitoring backend logs in Codespaces. Commit changes to GitHub, keeping both environments in sync and leveraging my CI/CD for deployment to the next environment. We can see the Dev Box running local frontend and the Codespace running the API connected to each other, making requests and displaying the data in the frontend! Hybrid advantage: Dev Box handles GUI previews comfortably and allows me to live test frontend changes. Codespaces handles production-aligned backend testing and Linux-native tools. Dev Box allows me to view all of my files in one screen with potentially multiple Codespaces running in browser of VS Code Desktop. Due to all of those platform efficiencies I have completed my days goals within an hour or two and now I can spend the rest of my day learning about how to enable my developers to inner source using GitHub CoPilot and MCP (Shameless plug). The bottom line There are some additional considerations when architecting a developer platform for an enterprise such as private networking and security not covered in this post but these are implementation details to deliver the described developer experience. Architecting such a platform is a valuable investment to deliver the developer platform foundations we discussed at the top of the article. While in this demo I have quickly built I was working in a mono repository in real engineering teams it is likely (I hope) that an application is built of many different repositories. The great thing about Dev Box and Codespaces is that this wouldn’t slow down the rapid development I can achieve when using both. My Dev Box would be specific for the project or development team, pre loaded with all the tools I need and potentially some repos too! When I need too I can quickly switch over to Codespaces and work in a clean isolated environment and push my changes. In both cases any changes I want to deliver locally are pushed into GitHub (Or ADO), merged and my CI/CD ensures that my next step, potentially a staging environment or who knows perhaps *Whispering* straight into production is taken care of. Once I’m finished I delete my Codespace and potentially my Dev Box if I am done with the project, knowing I can self service either one of these anytime and be up and running again! Now is there overlap in terms of what can be developed in a Codespace vs what can be developed in Azure Dev Box? Of course, but as organisations prioritise developer experience to ensure release velocity while maintaining organisational standards and governance then providing developers a windows native and Linux native service both of which are primarily charged on the consumption of the compute* is a no brainer. There are also gaps that neither fill at the moment for example Microsoft Dev Box only provides windows compute while GitHub Codespaces only supports VS Code as your chosen IDE. It's not a question of which service do I choose for my developers, these two services are better together! *Changes have been announced to Dev Box pricing. A W365 license is already required today and dev boxes will continue to be managed through Azure. For more information please see: Microsoft Dev Box capabilities are coming to Windows 365 - Microsoft Dev Box | Microsoft LearnAnnouncing the Public Preview of the New App Service Quota Self-Service Experience
Update 10/30/2025: The App Service Quota Self-Service experience is back online after a short period where we were incorporating your feedback and making needed updates. As this is public preview, availability and features are subject to change as we receive and incorporate feedback. What’s New? The updated experience introduces a dedicated App Service Quota blade in the Azure portal, offering a streamlined and intuitive interface to: View current usage and limits across the various SKUs Set custom quotas tailored to your App Service plan needs This new experience empowers developers and IT admins to proactively manage resources, avoid service disruptions, and optimize performance. Quick Reference - Start here! If your deployment requires quota for ten or more subscriptions, then file a support ticket with problem type Quota following the instructions at the bottom of this post. If any subscription included in your request requires zone redundancy (note that most Isolated v2 deployments require ZR), then file a support ticket with problem type Quota following the instructions at the bottom of this post. Otherwise, leverage the new self-service experience to increase your quota automatically. Self-service Quota Requests For non-zone-redundant needs, quota alone is sufficient to enable App Service deployment or scale-out. Follow the provided steps to place your request. 1. Navigate to the Quotas resource provider in the Azure portal 2. Select App Service (Pubic Preview) Navigating the primary interface: Each App Service VM size is represented as a separate SKU. If the intention is to be able to scale up or down within a specific offering (e.g., Premium v3), then equivalent number of VMs need to be requested for each applicable size of that offering (e.g., request 5 instances for both P1v3 and P3v3). As with other quotas, you can filter by region, subscription, provider, or usage. Note that your portal will now show "App Service (Public Preview)" for the Provider name. You can also group the results by usage, quota (App Service VM type), or location (region). Current usage is represented as App Service VMs. This allows you to quickly identify which SKUs are nearing their quota limits. Adjustments can be made inline: no need to visit another page. This is covered in detail in the next section. Total Regional VMs: There is a SKU in each region called Total Regional VMs. This SKU summarizes your usage and available quota across all individual SKUs in that region. There are three key points about using Total Regional VMs. You should never request Total Regional VMs quota directly - it will automatically increase in response to your request for individual SKU quota. If you are unable to deploy a given SKU, then you must request more quota for that SKU to unblock deployment. For your deployment to succeed, you must have sufficient quota in the individual SKU as well as Total Regional VMs. If either usage is at its respective limit, then you will be unable to deploy and must request more of that individual SKU's quota to proceed. In some regions, Total Regional VMs appears as "0 of 0" usage and limit and no individual SKU quotas are shown. This is an indication that you should not interact with the portal to resolve any quota-related issues in this region. Instead, you should try the deployment and observe any error messages that arise. If any error messages indicate more quota is needed, then this must be requested by filing a support ticket with problem type Quota following the instructions at the bottom of this post so that App Service can identify and fix any potential quota issues. In most cases, this will not be necessary, and your deployment will work without requesting quota wherever "0 of 0" is shown for Total Regional VMs and no individual SKU quotas are visible. See the example below: 3. Request quota adjustments Clicking the pen icon opens a flyout window to capture the quota request: The quota type (App Service SKU) is already populated, along with current usage. Note that your request is not incremental: you must specify the new limit that you wish to see reflected in the portal. For example, to request two additional instances of P1v2 VMs, you would file the request like this: Click submit to send the request for automatic processing. How quota approvals work: Immediately upon submitting a quota request, you will see a processing dialog like the one shown: If the quota request can be automatically fulfilled, then no support request is needed. You should receive this confirmation within a few minutes of submission: If the request cannot be automatically fulfilled, then you will be given the option to file a support request with the same information. In the example below, the requested new limit exceeds what can be automatically granted for the region: 4. If applicable, create support ticket When creating a support ticket, you will need to repopulate the Region and App Service plan details; the new limit has already been populated for you. If you forget the region or SKU that was requested, you can reference them in your notifications pane: If you choose to create a support ticket, then you will interact with the capacity management team for that region. This is a 24x7 service, so requests may be created at any time. Once you have filed the support request, you can track its status via the Help + support dashboard. Known issues The self-service quota request experience for App Service is in public preview. Here are some caveats worth mentioning while the team finalizes the release for general availability: Closing the quota request flyout window will stop meaningful notifications for that request. You can still view the outcome of your quota requests by checking actual quota, but if you want to rely on notifications for alerts, then we recommend leaving the quota request window open for the few minutes that it is processing. Some SKUs are not yet represented in the quota dashboard. These will be added later in the public preview. The Activity Log does not currently provide a meaningful summary of previous quota requests and their outcomes. This will also be addressed during the public preview. As noted in the walkthrough, the new experience does not enable zone-redundant deployments. Quota is an inherently regional construct, and zone-redundant enablement requires a separate step that can only be taken in response to a support ticket being filed. Quota API documentation is being drafted to enable bulk non-zone redundant quota requests without requiring you to file a support ticket. Filing a Support Ticket If your deployment requires zone redundancy or contains many subscriptions, then we recommend filing a support ticket with issue type "Technical" and problem type "Quota": We want your feedback! If you notice any aspect of the experience that does not work as expected, or you have feedback on how to make it better, please use the comments below to share your thoughts!Exploring Traffic Manager Integration for External DNS
When you deploy externally accessible applications into Kubernetes, there is usually a requirement for creating some DNS records pointing to these applications, to allow your users to resolve them. Rather than manually creating these DNS records, there are tools that will do this work for you, one of which is External DNS. External DNS can watch your Kubernetes resource configuration for specific annotations and then use these to create DNS records in your DNS zone. It has integrations with many DNS providers, including Azure DNS. This solution works well and is in use by many customers using AKS and Azure DNS. Where we hit a limitation with External DNS in Azure is in scenarios where we are need to distribute traffic across multiple clusters for load balancing and global distribution. There are a few ways to achieve this global distribution in Azure, one way is to use Azure Traffic Manger. Unlike something like Azure Front Door, Azure Traffic Manager is a DNS based global load balancer. Traffic is directed to your different AKS clusters based on DNS resolution using Traffic Manager. When a user queries your Traffic Manager CNAME, they hit the Traffic Manager DNS servers, which then return a DNS record for a specific cluster based on your load balancing configuration. Traffic Manager can then introduce advanced load balancing scenarios such as: Geographic routing - direct users to the nearest endpoint based on their location Weighted distribution - split traffic percentages (e.g., 80% to one region, 20% to another) Priority-based failover - automatic disaster recovery with primary/backup regions Performance-based routing - direct users to the endpoint with lowest latency So, given Azure Traffic Manager is a essentially a DNS service, it would be good if we could manage it using External DNS. We already use External DNS to create DNS records for each of our individual clusters, so why not use it to also create the Traffic Manager DNS configuration to load balance across them. This would also provides the added benefit of allowing us to change our load balancing strategy or configuration by making changes to our External DNS annotations. Unfortunately, an External DNS integration for Traffic Manager doesn't currently exist. In this post, I'll walk through a proof-of-concept for a provider I built to explore whether this integration is viable, and share what I learned along the way. External DNS Webhook Provider External DNS has two types of integrations. The first, and most common for "official" providers are "In-tree" providers, which are the integrations that have been created by External DNS contributors and sit within the central External DNS repository. This includes the Azure DNS provider. The second type of provider is the WebHook provider, which allows for external contributors to easily create their own providers without the need to submit them to the core External DNS repo and go through that release process. We are going to use the WebHook provider External DNS has begun the process of phasing out "In-tree" providers and replacing with WebHook ones. No new "In-tree" providers will be accepted. By using the WebHook provider mechanism, I was able to create a proof of concept Azure Traffic Manager provider that does the following: Watches Kubernetes Services for Traffic Manager annotations Automatically creates and manages Traffic Manager profiles and endpoints Syncs state between your Kubernetes clusters and Azure Enables annotation-driven configuration - no manual Traffic Manager management needed Handles duplication so that when your second cluster attempts to create a Traffic Manager record it adds an endpoint to the existing instance Works alongside the standard External DNS Azure provider for complete DNS automation Here's what the architecture looks like: Example Configuration: Multi-Region Deployment Let me walk you through a practical example using this provider to see how it works. We will deploy an application across two Azure regions with weighted traffic distribution and automatic failover. This example assumes you have built and deployed the PoC provider as discussed below. Step 1: Deploy Your Application You deploy your application to both East US and West US AKS clusters. Each deployment is a standard Kubernetes Service with LoadBalancer type. We then apply annotations that tell our External DNS provider how to create and configure the Traffic Manger resource. These annotations are defined as part of our plugin. apiVersion: v1 kind: Service metadata: name: my-app-east namespace: production annotations: # Standard External DNS annotation external-dns.alpha.kubernetes.io/hostname: my-app-east.example.com # Enable Traffic Manager integration external-dns.alpha.kubernetes.io/webhook-traffic-manager-enabled: "true" external-dns.alpha.kubernetes.io/webhook-traffic-manager-resource-group: "my-tm-rg" external-dns.alpha.kubernetes.io/webhook-traffic-manager-profile-name: "my-app-global" # Weighted routing configuration external-dns.alpha.kubernetes.io/webhook-traffic-manager-weight: "70" external-dns.alpha.kubernetes.io/webhook-traffic-manager-endpoint-name: "east-us" external-dns.alpha.kubernetes.io/webhook-traffic-manager-endpoint-location: "eastus" # Health check configuration external-dns.alpha.kubernetes.io/webhook-traffic-manager-monitor-path: "/health" external-dns.alpha.kubernetes.io/webhook-traffic-manager-monitor-protocol: "HTTPS" spec: type: LoadBalancer ports: - port: 443 targetPort: 8080 selector: app: my-app The West US deployment has identical annotations, except: Weight: "30" (sending 30% of traffic here initially) Endpoint name: "west-us" Location: "westus" Step 2: Automatic Resource Creation When you deploy these Services, here's what happens automatically: Azure Load Balancer provisions and assigns public IPs to each Service External DNS (Azure provider) creates A records: my-app-east.example.com → East US LB IP my-app-west.example.com → West US LB IP External DNS (Webhook provider) creates a Traffic Manager profile named my-app-global Webhook adds endpoints to the profile: East endpoint (weight: 70, target: my-app-east.example.com) West endpoint (weight: 30, target: my-app-west.example.com) External DNS (Azure provider) creates a CNAME: my-app.example.com → Traffic Manager FQDN Now when users access my-app.example.com, Traffic Manager routes 70% of traffic to East US and 30% to West US, with automatic health checking on both endpoints. Step 3: Gradual Traffic Migration Want to shift more traffic to West US? Just update the annotations: kubectl annotate service my-app-east \ external-dns.alpha.kubernetes.io/webhook-traffic-manager-weight="50" \ --overwrite kubectl annotate service my-app-west \ external-dns.alpha.kubernetes.io/webhook-traffic-manager-weight="50" \ --overwrite Within minutes, traffic distribution automatically adjusts to 50/50. This enables: Blue-green deployments - test new versions with small traffic percentages Canary releases - gradually increase traffic to new deployments Geographic optimisation - adjust weights based on user distribution Step 4: Automatic Failover If the East US cluster becomes unhealthy, Traffic Manager's health checks detect this and automatically fail over 100% of traffic to West US, no manual intervention required. How It Works The webhook implements External DNS's webhook provider protocol: 1. Negotiate Capabilities External DNS queries the webhook to determine supported features and versions. 2. Adjust Endpoints External DNS sends all discovered endpoints to the webhook. The webhook: Filters for Services with Traffic Manager annotations Validates configuration Enriches endpoints with metadata Returns only Traffic Manager-enabled endpoints 3. Record State External DNS queries the webhook for current Traffic Manager state. The webhook: Syncs profiles from Azure Converts to External DNS endpoint format Returns CNAME records pointing to Traffic Manager FQDNs 4. Apply Changes External DNS sends CREATE/UPDATE/DELETE operations. The webhook: Creates Traffic Manager profiles as needed Adds/updates/removes endpoints Configures health monitoring Updates in-memory state cache The webhook uses Azure SDK for Go to interact with the Traffic Manager API and maintains an in-memory cache of profile state to optimise performance and reduce API calls. Proof of Concept 🛑 Important: This is a Proof of Concept This project is provided as example code to demonstrate the integration pattern between External DNS and Traffic Manager. It is not a supported product and comes with no SLAs, warranties, or commitments. The code is published to help you understand how to build this type of integration. If you decide to implement something similar for your production environment, you should treat this as inspiration and build your own solution that you can properly test, secure, and maintain. Think of this as a blueprint, not a finished product. With that caveat out of the way, if you want to experiment with this approach, the PoC is available on GitHub: github.com/sam-cogan/external-dns-traffic-manager. The readme file containers detailed instructions on how to deploy the PoC into a single and multi-cluster environment, along with demo applications to try it out. Use Cases This integration unlocks several powerful scenarios: Multi-Region High Availability - Deploy your application across multiple Azure regions with automatic DNS-based load balancing and health-based failover. No additional load balancers or gateways required. Blue-Green Deployments - Deploy a new version alongside your current version, send 5% of traffic to test, gradually increase, and roll back instantly if issues arise by changing annotations. Geographic Distribution - Route European users to your Europe region and US users to your US region automatically using Traffic Manager's geographic routing with the same annotation-based approach. Disaster Recovery - Configure priority-based routing with your primary region at priority 1 and DR region at priority 2. Traffic automatically fails over when health checks fail. Cost Optimisation - Use weighted routing to balance traffic across regions based on capacity and costs. Send more traffic to regions where you have reserved capacity or lower egress costs. Considerations and Future Work This is a proof of concept and should be thoroughly tested before production use. Some areas for improvement: Current Limitations In-memory state only - no persistent storage (restarts require resync) Basic error handling - needs more robust retry logic Limited observability - could use more metrics and events Manual CRD cleanup - DNSEndpoint CRDs need manual cleanup when switching providers Potential Enhancements Support for more endpoint types - currently focuses on ExternalEndpoints Advanced health check configuration - custom intervals, timeouts, and thresholds Metric-based routing decisions - integrate with Azure Monitor for intelligent routing GitOps integration - Flux/ArgoCD examples and best practices Helm chart - simplified deployment If you try this out or have ideas for improvements, please open an issue or PR on GitHub. Wrapping Up This proof of concept shows that External DNS and Traffic Manager can work together nicely. Since Traffic Manager is really just an advanced DNS service, bringing it into External DNS's annotation-driven workflow makes a lot of sense. You get the same declarative approach for both basic DNS records and sophisticated traffic routing. While this isn't production-ready code (and you shouldn't use it as-is), it demonstrates a viable pattern. If you're dealing with multi-region Kubernetes deployments and need intelligent DNS-based routing, this might give you some ideas for building your own solution. The code is out there for you to learn from, break, and hopefully improve upon. If you build something based on this or have feedback on the approach, I'd be interested to hear about it. Resources GitHub Repository: github.com/sam-cogan/external-dns-traffic-manager External DNS Documentation: kubernetes-sigs.github.io/external-dns Azure Traffic Manager: learn.microsoft.com/azure/traffic-manager Webhook Provider Guide: External DNS Webhook TutorialIntroducing the Azure Static Web Apps Skill for GitHub Copilot
From "Built" to "Deployed" in Minutes You've just finished building something great: A marketing landing page for your startup A portfolio site showcasing your work A documentation site for your open-source project An e-commerce storefront built with Next.js An internal dashboard for your team A blog with your latest content Now you want to share it with the world. Azure Static Web Apps offers free hosting, global CDN, custom domains, and built-in auth—but figuring out the deployment workflow can slow you down. The learning curve: "What's the CLI command again? Is it swa-cli or @azure/static-web-apps-cli? Where does staticwebapp.config.json go?" The golden path: "Hey Copilot, deploy my Vite app to Azure Static Web Apps" The skill provides a streamlined, tested workflow—the golden path—so you can focus on your app, not the deployment process. What Are Agent Skills? Agent Skills are self-contained knowledge bundles that enhance GitHub Copilot's capabilities for specialized tasks. They provide a curated, golden path for common workflows: Feature Benefit Curated Commands Exact CLI syntax that works today Guardrails Knows what NOT to do (e.g., never manually create swa-cli.config.json) Troubleshooting Built-in solutions for common errors Framework Awareness Knows Vite uses port 5173, React uses 3000 The Traditional Approach: Learning as You Go Deploying to Azure Static Web Apps is straightforward once you know the workflow, but the learning curve can add time to your first deployment: Typical First-Time Challenges Finding the right tools: Azure has multiple CLI options—the Azure CLI extension (az staticwebapp) for managing resources, and the SWA CLI (@azure/static-web-apps-cli) for local development and deployment. Knowing which to use when takes research. Configuration decisions: Where does staticwebapp.config.json go? Should you use swa init or create configs manually? What's the right build output path for your framework? Framework-specific setup: Different frameworks have different port numbers, build commands, and output directories. Vite uses port 5173, Create React App uses 3000, Next.js has its own conventions. SPA routing: Client-side routing needs navigationFallback configuration—something you might not discover until you see 404 errors in production. Typical First Deployment: 25-45 minutes This time includes reading documentation, trying commands, and troubleshooting configuration. Not wrong—just a learning process that the skill can accelerate. The Golden Path: With the Azure Static Web Apps Skill The skill provides a streamlined workflow that guides you through each step—whether you're deploying a portfolio, marketing site, or enterprise application: Step 1: Install and Initialize (30 seconds) You: "Set up my Vite React app for Azure Static Web Apps" Copilot (with skill): "I'll help you set up SWA for your Vite app: 1. Install the CLI: npm install -D @azure/static-web-apps-cli 2. Initialize (auto-detects Vite framework): npx swa init --yes" Correct package, correct command, framework auto-detected! Step 2: Local Development (15 seconds) You: "Run it locally" Copilot (with skill): "Start the local emulator: npx swa start Open http://localhost:4280 to test." Dev server proxy automatically configured! Step 3: Deploy (30 seconds) You: "Deploy to Azure" Copilot (with skill): "Deploy to production: npx swa login npx swa deploy --env production" Correct commands AND proactive troubleshooting advice! Total Time: Under 3 minutes The skill provides the golden path—tested commands, framework awareness, and proactive guidance. Side-by-Side Comparison Task Learning Curve Golden Path (with Skill) Find correct CLI Research docs Instant guidance Create config Trial and error swa init --yes Local dev setup Framework research Auto-detected Deployment Documentation reading Guided workflow Total Time 25-45 minutes < 3 minutes Confidence Level Learning Guided Understanding Azure Static Web Apps Tooling Azure provides multiple tools for working with Static Web Apps. The skill helps you navigate these options by providing the golden path for each scenario: Two Complementary Tools Tool Purpose Install Command Azure CLI extension (az staticwebapp) Manage Azure resources Built into Azure CLI SWA CLI (swa) Local development, deploying apps npm install -D azure/static-web-apps-cli Both tools serve important purposes, and the skill guides you to the right one for your task. The Skill Provides the Golden Path The skill guides you through: The right tool for your task The recommended workflow: swa init → swa start → swa deploy Framework detection (Vite, React, Vue, Next.js, and more) Best practices like using swa init for configuration What the Skill Knows Best Practices Built In Best Practice Why It Matters Use swa init for configuration Auto-detects framework settings Framework-specific ports Vite uses 5173, React uses 3000, etc. navigationFallback for SPAs Prevents 404s on client-side routes platform.apiRuntime for APIs Required for Azure Functions integration Built-in Troubleshooting Common Issue Skill's Solution 404 on client routes Add navigationFallback API returns 404 Check apiRuntime and function exports Build output not found Verify output_location matches build CORS errors APIs under /api/* are same-origin Installing the Skill There are two ways to install the skill: using GitHub Copilot CLI (recommended) or manually adding the skill file. Option 1: GitHub Copilot CLI (Recommended) The fastest way to get started is using the Copilot CLI plugin system: # Add the repo as a plugin marketplace /plugin marketplace add microsoft/github-copilot-for-azure # Install the Azure plugin (includes Static Web Apps skill) /plugin install azure@github-copilot-for-azure # Update the plugin when changes are made /plugin update azure@github-copilot-for-azure Option 2: Manual Installation If you prefer to install the skill manually: 1. Create the Skill Folder your-project/ └── skills/ └── azure-static-web-apps/ └── SKILL.md 2. Copy the Skill Content The skill file contains: Overview of Azure Static Web Apps capabilities Installation commands with verification Configuration guidance for both config files Command reference for all SWA CLI commands Scenarios for common workflows Troubleshooting for common issues Get the skill: github.com/github/awesome-copilot Try It Yourself Prompt What Copilot Does "Deploy my React app to SWA" Full workflow: install → init → build → deploy "Add authentication to my routes" Configures staticwebapp.config.json with auth rules "Set up GitHub Actions for SWA" Generates complete CI/CD workflow "Why am I getting 404 on /dashboard" Identifies missing navigationFallback "Add an API backend" Creates Azure Functions with correct runtime config Key Takeaways Time Savings: What takes 30-45 minutes now takes under 3 minutes with guided, accurate commands Best Practices: The skill encodes best practices—guiding you through the recommended workflow Curated Guidance: Skills contain curated, tested commands for the golden path deployment Context-Aware: Framework-specific knowledge means less configuration guessing Learn More Agent Skills Specification: agentskills.io/specification Azure Static Web Apps Docs: learn.microsoft.com/azure/static-web-apps SWA CLI Reference: azure.github.io/static-web-apps-cli More Skills: github.com/github/awesome-copilot Have you tried Agent Skills? Share your experience deploying to Azure Static Web Apps in the comments!How SRE Agent Pulls Logs from Grafana and Creates Jira Tickets Without Native Integrations
Your tools. Your workflows. SRE Agent adapts. SRE Agent natively integrates with PagerDuty, ServiceNow, and Azure Monitor. But your team might use Jira for incident tracking. Grafana for dashboards. Loki for logs. Prometheus for metrics. These aren't natively supported. That doesn't matter. SRE Agent supports MCP, the Model Context Protocol. Any MCP-compatible server extends the agent's capabilities. Connect your Grafana instance. Connect your Jira. The agent queries logs, correlates errors, and creates tickets with root cause analysis across tools that were never designed to talk to each other. The Scenario I built a grocery store app that simulates a realistic SRE scenario: an external supplier API starts rate limiting your requests. Customers see "Unable to check inventory" errors. The on-call engineer gets paged. The goal: SRE Agent should diagnose the issue by querying Loki logs through Grafana, identify the root cause, and create a Jira ticket with findings and recommendations. The app runs on Azure Container Apps with Loki for logs and Azure Managed Grafana for visualization. 👉 Deploy it yourself: github.com/dm-chelupati/grocery-sre-demo How I Set Up SRE Agent: Step by Step Step 1: Create SRE Agent I created an SRE Agent and gave it Reader access to my subscription Step 2: Connect to Grafana and Jira via MCP Neither MCP server had a remotely hosted option, and their stdio setup didn't match what SRE Agent supports. So I hosted them myself as Azure Container Apps: Grafana MCP Server — connects to my Azure Managed Grafana instance Atlassian MCP Server — connects to my Jira Cloud instance Now I have two endpoints SRE Agent can reach: https://ca-mcp-grafana.<env>.azurecontainerapps.io/mcp https://ca-mcp-jira.<env>.azurecontainerapps.io/mcp I added both to SRE Agent's MCP configuration as remotely hosted servers. Step 3: Create Sub-Agent with Tools and Instructions I created a sub-agent specifically for incident diagnosis with these tools enabled: Grafana MCP (for querying Loki logs) Atlassian MCP (for creating Jira tickets) Instructions were simple: You are expert in diagnosing applications running on Azure services. You need to use the Grafana tools to get the logs, metrics or traces and create a summary of your findings inside Jira as a ticket. use your knowledge base file loki-queries.md to learn about app configuration with loki and Query the loki for logs in Grafana. Step 4: Invoke Sub-Agent and Watch It Work I went to the SRE Agent chat and asked: @JiraGrafanaexpert: My container app ca-api-3syj3i2fat5dm in resource group rg-groceryapp is experiencing rate limit errors from a supplier API when checking product inventory. The agent: Queried Loki via Grafana MCP: {app="grocery-api"} |= "error" Found 429 rate limit errors spiking — 55+ requests hitting supplier API limits Identified root cause: SUPPLIER_RATE_LIMIT_429 from FreshFoods Wholesale API Created a Jira ticket: One prompt. Logs queried. Root cause identified. Ticket created with remediation steps. Making It Better: The Knowledge File SRE Agent can explore and discover how your apps are wired but you can speed that up. When querying observability data sources, the agent needs to learn the schema, available labels, table structures, and query syntax. For Loki, that means understanding LogQL, knowing which labels your apps use, and what JSON fields appear in logs. SRE Agent can figure things out, but with context, it gets there faster — just like humans. I created a knowledge file that gives the agent a head start: With this context, the agent knows exactly which labels to query, what fields to extract from JSON logs, and which query patterns to use 👉 See my full knowledge file How MCP Makes This Possible SRE Agent supports two ways to connect MCP servers: stdio — runs locally via command. This works for MCP servers that can be invoked via npx, node, or uvx. For example: npx -y @modelcontextprotocol/server-github. Remotely hosted — HTTP endpoint with streamable transport: https://mcp-server.example.com/sse or /mcp The catch: Not every MCP server fits these options out of the box. Some servers only support stdio but not the npx/node/uvx formats SRE Agent expects. Others don't offer a hosted endpoint at all. The solution: host them yourself. Deploy the MCP server as a container with an HTTP endpoint. That's what I did with Grafana MCP Server and Atlassian MCP Server, deployed both as Azure Container Apps exposing /mcp endpoints. Why This Matters Enterprise tooling is fragmented across Azure and non-Azure ecosystems. Some teams use Azure Monitor, others use Datadog. Incident tracking might be ServiceNow in one org and Jira in another. Logs live in Loki, Splunk, Elasticsearch and sometimes all three. SRE Agent meets you where you are. Azure-native tools work out of the box. Everything else connects via MCP. Your observability stack stays the same. Your ticketing system stays the same. The agent becomes the orchestration layer that ties them together. One agent. Any tool. Intelligent workflows across your entire ecosystem. Try It Yourself Create an SRE Agent Deploy MCP servers for your tools (Grafana, Atlassian) Create a sub-agent with the MCP tools connected Add a knowledge file with your app context Ask it to diagnose an issue Watch logs become tickets. Errors become action items. Context becomes intelligence. Learn More Azure SRE Agent documentation Azure SRE Agent blogs Grocery SRE Demo repo MCP specification Azure SRE Agent is currently in preview.
