The Kudu Debug Console, Azure Websites best kept secret

Guest blog post from Azure MVP Guy Barrette

One of the advantages of using Azure Websites (now Web Apps in the Azure App Service) is that it’s a Platform-as-a-Service, meaning that you don’t have to maintain and patch the operating system but as a side effect, you can’t use remote desktop to connect directly to the machine even if you use the Standard service tier where you have your own VM. So what if you want to have a little more control over your Websites? The solution is to use the best kept Azure Websites secret: the Kudu debug console.

Kudu is the engine behind git deployments, WebJobs, and various other features in Azure Web Sites. Kudu is open source and you can find the source code at GitHub. In this article, I’ll focus on Kudu’s debug console.

So what do you need to install and configure to access this super secret debug console? Nothing, it’s already there waiting for you. Simply insert SCM in the URL of your Website between the Website name and the domain like this:

If you’re not already authenticated, you’ll have to enter your Azure credentials to access the console.


Clicking on the Environment link at the top of the screen will take you to a page listing useful information when debugging:

  • System Info
  • App Settings
  • Connection Strings
  • Environment variables
  • PATH
  • HTTP Headers
  • Server variables

The Debug Console link gives you the option to open a command line or a PowerShell console.


You can use the UI and/or use the console to navigate the file system and the UI gives you icons to edit, delete or download a file.


So let’s say that you’re visiting friends and you receive that 3AM call asking you to fix something and you don’t have your laptop but have access to a browser. Well, you can do some basic fixes and changes right from the Kudu Debug Console. Using Internet Explorer, it’s even possible to upload files to your site by dragging & dropping them directly to the console. Now remember that you’re editing the live site here so be careful and don’t forget to change the source in the repository later. I know, best practices say “don’t do this!” but at 3AM, with a site down, you may be happy to have direct access to your site just by using a browser :-).

The Process Explorer link will take you to a page listing the processes currently running.


Clicking the Properties link will pop a window listing tons of information about the process.


And useful action buttons.


Notice that there are two W3wp.exe processes running: the main site and the SCM (Kudu) site but WebJobs would also appear here. So let’s say that there’s a bug in your WebJob and it is stuck, you can kill the process without restarting the whole site.

If you turned on diagnostic logging, the Tools menu gives you the option to download the logs and using the Support link, you have a nice UI giving you links to download the log files individually.


You also have access to the event logs and filter them by level, date, ID and source.


Now who said that having no RDP access to your WebSites virtual machine is a limitation? 😉

Comments (2)
  1. Dominic Marchand says:

    Awesome, thanks for that info ! Was using Web Roles mostly for RDP access so that is very pertinent. Is that as convenient when multiple servers are used to host a website ? For example, can I access, from the same * interface, data like processes and system logs by server instance in the farm, or will I just get this data from the server where kudu/SCM runs ? And if I edit a file, will it be pushed on all instances ? I'll make sure to test it nonetheless but am curious to know more on this aspect.

  2. Guy Barrette says:


    Websites use sticky sessions by default, the load balancer will direct you to one instance and send you an ARRAffinity cookie so you hit the same server during your session.  Using the Kudu debug console, you get the same result.  Is all lost?  Not at all!  Check this blog post from a member of the Websites team:…/access-specific-instance

    Editing files: all instances share the same files so if you edit/save/create/delete a file, all instances will see the change.

Comments are closed.

Skip to main content