App Service
432
Total Pages
240
Linux-Friendly Pages
192
Pages with Bias
44.4%
Bias Rate
Bias Trend Over Time
Pages with Bias Issues
2121 issues found
Showing 351-375 of 2121 flagged pages
App Service
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/app-service/overview-local-cache.md
...blob/main/articles/app-service/overview-local-cache.md
High Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Missing Linux Example
Summary
The documentation demonstrates a Windows-first bias by referencing Windows-style paths (e.g., D:\home), using Windows terminology and folder structures throughout, and mentioning Windows containers before Linux containers. There are no Linux-specific examples or equivalent Linux path references, and tools or instructions that would be familiar to Linux users are absent. The only tool mentioned for checking disk usage is a GUI site extension, with no mention of command-line alternatives suitable for Linux users.
Recommendations
- Include Linux path equivalents (e.g., /home/site) alongside Windows paths in all examples and explanations.
- When discussing containers, mention Linux containers first or provide parallel instructions/examples for both Windows and Linux containers.
- Provide Linux-friendly methods for checking folder sizes (e.g., using du in Kudu SSH/console) in addition to the Azure Web Apps Disk Usage extension.
- Clarify any differences in local cache behavior or configuration for Linux-based App Service plans.
- Ensure that all code snippets, environment variable checks, and troubleshooting steps are applicable to both Windows and Linux environments, or clearly indicate platform-specific differences.
Create Pull Request
App Service
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/app-service/reference-app-settings.md
...ob/main/articles/app-service/reference-app-settings.md
High Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Powershell Heavy
Missing Linux Example
Summary
The documentation page demonstrates a Windows bias in several ways: Windows-specific paths and tools are often mentioned first or exclusively (e.g., 'D:\home', references to 'w3wp.exe', 'applicationHost.config', and Windows-specific environment variables). Many settings and explanations are tailored to Windows App Service or native Windows apps, with Linux equivalents either mentioned later, less prominently, or omitted. Some examples and defaults reference Windows conventions (such as time zones linked to Windows documentation, or logging paths using Windows syntax). In build automation, the Kudu (Windows) section is more detailed and comes before the Oryx (Linux) section. Several environment variables are described as 'Windows only' or have Windows-specific behaviors, with Linux alternatives not always fully explained.
Recommendations
- For every Windows-specific example or path (e.g., 'D:\home'), provide the Linux equivalent (e.g., '/home').
- When referencing tools or processes (e.g., 'w3wp.exe', 'applicationHost.config'), also mention the Linux or cross-platform alternatives, or clarify when they are not applicable.
- Avoid linking only to Windows documentation (such as time zones); include Linux/Unix equivalents or note differences.
- Present Linux and Windows options in parallel, rather than always listing Windows first.
- Expand the Oryx (Linux) build automation section to match the detail of the Kudu (Windows) section, and ensure parity in explanations and examples.
- Clearly indicate when a setting is platform-specific, and provide guidance for both platforms where possible.
- Where defaults differ by platform, explicitly state the default for each (not just for Windows).
App Service
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/app-service/quickstart-nodejs.md
...cs/blob/main/articles/app-service/quickstart-nodejs.md
High Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Powershell Heavy
Missing Linux Example
Summary
The documentation provides both Linux and Windows deployment paths, but there are subtle biases favoring Windows. In Visual Studio Code deployment, the Windows instructions are more detailed and include extra steps (such as web.config generation) that are not paralleled for Linux. Windows-specific tools and patterns (like web.config, Application Insights, and certain App Service settings) are mentioned without Linux equivalents or context. The CLI and portal sections default to Linux but still reference Windows-specific options. There is also a lack of explicit Linux troubleshooting or configuration guidance where Windows gets extra notes.
Recommendations
- Ensure Linux and Windows instructions are equally detailed, especially in Visual Studio Code deployment steps.
- When mentioning Windows-specific concepts (e.g., web.config, Application Insights), provide Linux equivalents or clarify that they are not needed on Linux.
- Add troubleshooting tips and notes for Linux deployments, similar to the extra guidance given for Windows.
- Avoid presenting Windows-specific steps or tools before Linux ones unless Linux is the default/recommended path.
- Where possible, use cross-platform terminology and avoid assuming Visual Studio Code or Azure App Service behaviors are identical across OSes—call out differences explicitly.
- Include explicit examples or notes for common Linux shell environments (bash, zsh) when providing command-line instructions.
App Service
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/app-service/troubleshoot-dotnet-visual-studio.md
...icles/app-service/troubleshoot-dotnet-visual-studio.md
High Priority
View Details →
Detected Bias Types
Windows First
Missing Linux Example
Windows Tools
Powershell Heavy
Summary
The documentation is heavily oriented toward Windows and Visual Studio workflows, with all examples and instructions assuming the use of Visual Studio on Windows. There are no references to Linux, macOS, or cross-platform tools, and all file paths, tools (e.g., Server Explorer, Output window), and troubleshooting steps are specific to the Windows ecosystem. Windows-specific tools like Log Parser and IIS are mentioned, while Linux equivalents or cross-platform alternatives are absent. No command-line or non-GUI (CLI) approaches are provided, and there is no mention of how to perform similar troubleshooting on Linux-based App Service environments or from non-Windows development environments.
Recommendations
- Add equivalent instructions and examples for troubleshooting Azure App Service apps using cross-platform tools such as Visual Studio Code, Azure CLI, and Azure Portal.
- Include Linux/macOS workflows for remote debugging, log streaming, and file access, especially for developers not using Visual Studio on Windows.
- Reference and provide examples for using Azure CLI and/or Azure Cloud Shell to enable and access logs, download files, and perform remote debugging.
- Mention and document open-source or cross-platform log analysis tools (e.g., jq, grep, awk, GoAccess) alongside Windows tools like Log Parser.
- Clarify which features are only available on Windows or with Visual Studio, and provide alternatives or workarounds for Linux-based App Service plans.
- Add a section or callouts for Linux App Service troubleshooting, including differences in log locations, configuration, and available features.
App Service
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/app-service/app-service-managed-certificate-changes-july-2025.md
...e/app-service-managed-certificate-changes-july-2025.md
High Priority
View Details →
Detected Bias Types
Powershell Heavy
Windows Tools
Missing Linux Example
Summary
The documentation provides automation and scripting examples exclusively using PowerShell scripts for resource discovery and mitigation (e.g., identifying Traffic Manager endpoints and retrieving site config values). There are no equivalent examples or scripts for Linux/macOS users (such as Bash or cross-platform Azure CLI scripts). This creates a bias toward Windows users and may hinder Linux users from following the guidance efficiently.
Recommendations
- Provide equivalent Bash or cross-platform shell script examples for all PowerShell scripts referenced, especially for resource discovery and mitigation steps.
- When referencing downloadable scripts (e.g., from GitHub), include both PowerShell (.ps1) and Bash (.sh) versions, or at least mention alternatives for Linux/macOS users.
- Instruct users on how to use Azure CLI (which is cross-platform) for all automation tasks, and ensure that CLI examples are as detailed as PowerShell ones.
- Explicitly state that the PowerShell scripts are for Windows and provide guidance or links for Linux/macOS users.
- Review all automation and scripting guidance to ensure Linux parity and avoid assuming a Windows-first environment.
App Service
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/app-service/deploy-intelligent-apps-dotnet-to-azure-sql.md
...service/deploy-intelligent-apps-dotnet-to-azure-sql.md
High Priority
View Details →
Detected Bias Types
Windows First
Missing Linux Example
Windows Tools
Summary
The documentation demonstrates a bias toward Windows environments by referencing Windows-specific UI patterns (e.g., 'Right click', 'Save'), using tooling and workflows (such as Azure Data Studio and SQL Server Management Studio) that are more commonly associated with Windows, and omitting explicit Linux command-line or cross-platform instructions. There are no PowerShell scripts, but the absence of Linux-specific examples or CLI-based workflows makes it less accessible for Linux users.
Recommendations
- Provide equivalent Linux instructions for file operations (e.g., using 'dotnet new', 'touch', or editors like vim/nano instead of 'Right click').
- Include examples of connecting to Azure SQL using cross-platform tools such as Azure CLI, sqlcmd, or Data Studio on Linux.
- When referencing UI actions (like 'Right click'), add alternative command-line or editor-based steps.
- Explicitly mention that all code and deployment steps can be performed on Linux, and highlight any OS-specific considerations.
- Add screenshots or terminal commands for Linux environments where applicable.
- Ensure that all prerequisites and tooling (such as .NET SDK, Azure CLI, and editors) are referenced in a cross-platform manner.
App Service
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/app-service/app-service-configure-premium-v4-tier.md
...s/app-service/app-service-configure-premium-v4-tier.md
High Priority
View Details →
Detected Bias Types
Windows First
Powershell Heavy
Windows Tools
Missing Linux Example
Summary
The documentation demonstrates a moderate Windows bias. Windows terminology and tools (such as PowerShell) are presented prominently, and scripting examples are provided for both Azure CLI and Azure PowerShell, but not for Linux-native shells or tools. The order of presentation often puts Windows or PowerShell first, and there are no explicit Linux shell (bash) or deployment examples. While Linux is mentioned in SKU availability, parity in automation and scripting is lacking.
Recommendations
- Provide bash shell scripting examples alongside PowerShell for automation tasks.
- Ensure that Linux-specific deployment and configuration steps are included where relevant, especially for custom containers.
- When listing tools or commands, alternate the order or present Linux and Windows options together to avoid 'windows_first' bias.
- Clarify any differences in behavior or requirements between Windows and Linux App Service plans, especially in automation and scaling.
- Add explicit Linux-native guidance (e.g., using bash scripts, Linux CLI environments) for common tasks such as scaling and deployment.
App Service
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/app-service/configure-authentication-provider-apple.md
...app-service/configure-authentication-provider-apple.md
High Priority
View Details →
Detected Bias Types
Missing Linux Example
Windows Tools
Powershell Heavy
Summary
The documentation page demonstrates a bias toward Windows environments by providing only a C# example using the Microsoft.IdentityModel.Tokens NuGet package (commonly used in Windows/.NET development) for generating the client secret JWT. There are no Linux/Unix command-line examples (such as using OpenSSL or Python), and no mention of cross-platform tools or scripting languages. The documentation assumes familiarity with Windows-centric development tools and omits guidance for Linux users.
Recommendations
- Add Linux-friendly examples for generating the client secret JWT, such as using OpenSSL, Python (PyJWT), or Node.js (jsonwebtoken).
- Explicitly mention that the client secret can be generated on any platform, and provide at least one cross-platform, command-line example.
- Reference open-source, cross-platform libraries and tools in addition to the Microsoft.IdentityModel.Tokens NuGet package.
- Include sample shell commands or scripts that Linux/macOS users can run to accomplish the same tasks.
- Ensure that any instructions for configuring application settings or files are not specific to Windows file paths or tools.
App Service
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/app-service/app-service-configure-premium-v4-tier.md
...s/app-service/app-service-configure-premium-v4-tier.md
High Priority
View Details →
Detected Bias Types
Windows First
Powershell Heavy
Windows Tools
Missing Linux Example
Summary
The documentation demonstrates a Windows bias by presenting Windows information and tools before Linux equivalents, providing a PowerShell automation example but omitting a Bash/Linux shell script, and referencing Windows-specific patterns. Linux is mentioned, but Linux-specific automation and command-line examples are underrepresented.
Recommendations
- Provide Linux shell (bash) script examples alongside PowerShell for automation tasks.
- Present Linux and Windows information in parallel or in a neutral order, rather than Windows-first.
- Include examples and guidance for Linux container scenarios, especially since Premium V4 supports Linux custom containers.
- Reference cross-platform tools and workflows (e.g., Azure CLI, bash) before or alongside Windows-specific tools.
- Clarify any differences in steps or options for Linux users, especially where the Azure portal or CLI experience may differ.
App Service
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/app-service/app-service-managed-certificate-changes-july-2025.md
...e/app-service-managed-certificate-changes-july-2025.md
High Priority
View Details →
Detected Bias Types
Powershell Heavy
Windows Tools
Missing Linux Example
Windows First
Summary
The documentation exhibits a Windows bias by providing PowerShell scripts as the only automation example for identifying impacted Traffic Manager endpoints, referencing PowerShell as the primary scripting tool, and not offering equivalent Bash or cross-platform CLI scripts. Additionally, when linking to external scripts, only PowerShell solutions are mentioned, and there is no mention of Linux or macOS-specific workflows or tools. While Azure CLI and REST API references are present, the only concrete automation example is PowerShell-based, and PowerShell is mentioned before any cross-platform alternatives.
Recommendations
- Provide equivalent Bash or Azure CLI scripts for all PowerShell examples, especially for identifying Traffic Manager endpoints and retrieving site configuration details.
- Explicitly mention that PowerShell scripts can be run on Linux and macOS using PowerShell Core, or provide alternative instructions for those platforms.
- Where automation is discussed, offer both Windows (PowerShell) and Linux/macOS (Bash/CLI) options side by side.
- Reference cross-platform tools and workflows (such as Azure CLI, Bash, or Python scripts) equally or before Windows-specific tools.
- Add a note clarifying the cross-platform compatibility of all scripts and tools mentioned, and avoid assuming a Windows-only environment.
App Service
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/app-service/deploy-azure-pipelines.md
...ob/main/articles/app-service/deploy-azure-pipelines.md
High Priority
View Details →
Detected Bias Types
Windows First
Missing Linux Example
Windows Tools
Powershell Heavy
Summary
The documentation page demonstrates a moderate Windows bias. While it mentions both Linux and Windows App Service options, several examples and explanations are Windows-centric. Notably, the Web Deploy scenario is only shown with a Windows agent, and troubleshooting focuses on Windows-specific issues. There is a lack of Linux-specific deployment examples, and Windows tools and patterns (such as Web Deploy and IIS references) are mentioned without Linux equivalents or alternatives.
Recommendations
- Provide explicit Linux deployment examples, especially for scenarios where only Windows (e.g., Web Deploy) is currently covered.
- When mentioning deployment methods or tools (such as Web Deploy), clarify their platform limitations and suggest Linux alternatives (e.g., ZIP deploy, FTP, or Kudu REST API for Linux).
- Balance troubleshooting and FAQ sections by including common Linux agent issues and solutions, not just Windows-specific errors.
- In code samples and agent selection, alternate or parallelize examples for both 'windows-latest' and 'ubuntu-latest' where possible, especially in YAML snippets.
- Avoid assuming IIS or Windows-specific configuration (such as web.config or iisnode) unless clearly marked as Windows-only, and provide Linux equivalents or note their absence.
App Service
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/app-service/configure-gateway-required-vnet-integration.md
...service/configure-gateway-required-vnet-integration.md
High Priority
View Details →
Detected Bias Types
Windows First
Missing Linux Example
Windows Tools
Summary
The documentation exhibits a Windows bias by explicitly stating that gateway-required virtual network integration is only supported for Windows plans, with Linux apps being unsupported. All troubleshooting and connectivity examples use Windows-centric tools and commands (e.g., PowerShell's Test-NetConnection, netstat -aon), with no equivalent Linux instructions or examples. There is no mention of Linux-compatible approaches or tools, and the documentation does not provide parity for Linux users.
Recommendations
- Clearly state early in the documentation that gateway-required virtual network integration is not supported for Linux apps, and provide guidance or links for Linux users to alternative solutions (such as regional virtual network integration).
- Where troubleshooting steps are provided (e.g., using PowerShell's Test-NetConnection or netstat), offer equivalent Linux commands (such as nc, curl, or ss) alongside the Windows examples.
- If possible, provide a table or section comparing feature support and troubleshooting steps for both Windows and Linux App Service plans.
- Ensure that any references to tools or commands (e.g., tcpping, netstat) include both Windows and Linux usage, or clarify if a tool is only available on one platform.
- In sections where only Windows portal UI or workflow is described, clarify if the same or similar options exist for Linux, or explicitly state if not applicable.
App Service
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/app-service/deploy-best-practices.md
...lob/main/articles/app-service/deploy-best-practices.md
High Priority
View Details →
Detected Bias Types
Windows First
Missing Linux Example
Windows Tools
Summary
The documentation page exhibits a Windows-first bias in several areas. Kudu is described primarily in the context of Windows App Service, with Linux mentioned as a secondary consideration. Deployment mechanisms such as WebDeploy (a Windows-centric tool) are listed without Linux equivalents like SCP or rsync. There are no explicit Linux command-line or shell script examples, and the language-specific sections (e.g., .NET) do not clarify cross-platform differences or provide Linux-specific guidance. The diagnostic and troubleshooting steps are described only through the Azure Portal UI, which is platform-agnostic but omits any CLI-based alternatives that might be more familiar to Linux users.
Recommendations
- Provide Linux-specific deployment examples, such as using SCP, rsync, or SFTP for file transfers.
- When mentioning Kudu, clarify its operation and differences on both Windows and Linux App Service environments.
- Include Bash or shell script examples alongside any PowerShell or Windows command-line instructions.
- List Linux-friendly deployment mechanisms and tools (e.g., Azure CLI, Git, rsync) alongside or before Windows-centric tools like WebDeploy.
- In language-specific sections, note any differences in deployment or build processes between Windows and Linux App Service.
- For diagnostics, offer Azure CLI or REST API alternatives to portal-based instructions, catering to users who prefer command-line tools.
App Service
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/app-service/configure-authentication-customize-sign-in-out.md
...vice/configure-authentication-customize-sign-in-out.md
High Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Missing Linux Example
Summary
The documentation contains a section on server-level authorization that is explicitly labeled as 'Windows apps only' and provides detailed instructions for configuring IIS via web.config, which is not applicable to Linux. There is no equivalent example or guidance for Linux-based apps, and the documentation does not mention Linux alternatives or patterns for fine-grained authorization at the server level. Additionally, the use of 'Windows apps only' and IIS/web.config patterns before any Linux discussion demonstrates a Windows-first approach.
Recommendations
- Provide equivalent examples or guidance for Linux-based App Service apps, such as using middleware in popular frameworks (e.g., Express.js for Node.js, Flask/Django for Python, etc.) to implement authorization.
- Explicitly mention that Linux apps require a different approach and link to relevant documentation or samples for Linux-based authorization patterns.
- Consider reordering or clearly separating Windows-only and cross-platform guidance to avoid implying that Windows is the default or primary platform.
- Where possible, include both Windows and Linux examples side by side when discussing platform-specific configuration.
App Service
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/app-service/configure-custom-container.md
...ain/articles/app-service/configure-custom-container.md
High Priority
View Details →
Detected Bias Types
Windows First
Powershell Heavy
Windows Tools
Missing Linux Example
Summary
The documentation demonstrates a moderate Windows bias. Windows-specific instructions, tools, and examples (such as PowerShell and Windows paths) are often presented before or in greater detail than their Linux counterparts. Some advanced configuration sections (like customizing memory, CPU, and health ping) provide PowerShell and Windows-centric details, while Linux-specific equivalents are less detailed or missing. Windows tools and patterns (e.g., Kudu, IIS, .NET Framework, Windows file paths) are referenced more frequently and with more depth. Linux examples are present, but sometimes as an afterthought or with less coverage.
Recommendations
- Ensure parity between Windows and Linux sections by providing equally detailed Linux examples and explanations for all advanced configuration topics (e.g., memory, CPU, health checks).
- When showing both Bash and PowerShell commands, present Bash (Linux) examples first or side-by-side, not always after PowerShell.
- Expand Linux-specific troubleshooting and diagnostic instructions to match the depth of Windows/Kudu coverage.
- Where Windows-specific tools (like Kudu, IIS, .NET Framework) are mentioned, provide Linux analogs or clarify their applicability.
- Audit for missing Linux examples (e.g., verifying CPU/memory limits inside Linux containers) and add them.
- Avoid assuming Windows file paths or conventions in general explanations; use neutral or dual examples.
- Review all sections for balance in terminology and depth, ensuring Linux users receive equivalent guidance.
App Service
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/app-service/configure-language-dotnet-framework.md
...les/app-service/configure-language-dotnet-framework.md
High Priority
View Details →
Detected Bias Types
Windows First
Missing Linux Example
Windows Tools
Summary
The documentation demonstrates a Windows bias by focusing on Windows-based deployment and configuration patterns for ASP.NET apps. Examples for listing .NET Framework versions use Windows file paths and Kudu's CMD/PowerShell consoles, with no Linux equivalents or mention of Linux-based App Service environments. The use of Visual Studio and Windows-specific deployment tools is emphasized, and Linux scenarios are only referenced in passing or as exceptions.
Recommendations
- Add explicit examples and instructions for configuring and deploying ASP.NET apps on Linux-based App Service plans, including how to check .NET versions and access environment variables.
- Provide Linux shell (bash) equivalents for commands currently shown only in CMD/PowerShell, especially for listing installed .NET versions.
- Mention Linux tools and workflows (such as SSH, bash, or Linux-based deployment pipelines) alongside Windows tools, not just as a footnote.
- Clarify which instructions apply to Windows App Service plans and which to Linux, and provide parity in guidance for both.
- Include screenshots or walkthroughs for Linux-based App Service environments where relevant.
App Service
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/app-service/configure-language-php.md
...ob/main/articles/app-service/configure-language-php.md
High Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Powershell Heavy
Missing Linux Example
Summary
The documentation generally provides parity between Windows and Linux by using platform pivots. However, there are several sections where Windows-specific tools and patterns (such as KuduScript, directory paths, and deployment script customization) are described in detail for Windows, while the Linux equivalents are either less detailed, missing, or require more manual steps. Windows examples and tools (like KuduScript and .dll extensions) are often described first or in more depth, and some automation patterns (custom deployment scripts for Composer, Bower, Gulp, Grunt) are only described for Windows. Linux users are sometimes directed to use manual shell commands or edit configuration files directly, with less guidance on automation or parity with Windows tooling.
Recommendations
- Ensure that all deployment automation examples (such as running Composer, Bower, Gulp, Grunt) are provided for Linux as well, not just Windows. If KuduScript or similar tooling is not available for Linux, suggest or document equivalent approaches (such as custom Oryx build hooks or startup scripts).
- Where Windows-specific tools or patterns are mentioned (e.g., KuduScript, .dll files, Windows directory paths), provide Linux equivalents immediately alongside or before the Windows examples.
- Expand the Linux sections to include more detailed, step-by-step automation and scripting guidance, matching the depth provided for Windows.
- Avoid assuming that users are familiar with manual shell editing (e.g., using echo to create .ini files); suggest or document more user-friendly alternatives if available.
- Review the order of presentation to ensure Linux is not always secondary to Windows, especially in cross-platform documentation.
- Where possible, provide a summary table or section that highlights differences and similarities between Windows and Linux approaches, to help users quickly find relevant guidance.
App Service
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/app-service/deploy-authentication-types.md
...in/articles/app-service/deploy-authentication-types.md
High Priority
View Details →
Detected Bias Types
Powershell Heavy
Windows Tools
Windows First
Missing Linux Example
Summary
The documentation page demonstrates a Windows bias by emphasizing Windows-centric tools and workflows such as Azure PowerShell, Visual Studio, and the App Service migration assistant for PowerShell scripts. These tools are either exclusive to Windows or primarily used in Windows environments. Linux-native deployment methods, such as Bash scripting or Linux CLI workflows, are not mentioned or exemplified. Visual Studio Code is listed, but its example is focused on .NET, which is also traditionally Windows-centric. There are no explicit Linux shell or cross-platform examples, and Windows tools are often mentioned before or instead of Linux alternatives.
Recommendations
- Include Linux shell (Bash) and cross-platform CLI examples alongside or before PowerShell examples.
- Highlight cross-platform tools (such as Azure CLI) with explicit Linux usage scenarios.
- Add references to Linux-native editors (such as Vim, Emacs) or deployment workflows (e.g., SCP, rsync, Git from Linux).
- Provide parity in documentation for Linux users, such as migration tools or scripts that run natively on Linux.
- Ensure that Visual Studio Code examples include non-.NET languages and Linux deployment scenarios.
- Where PowerShell is referenced, also provide equivalent Bash or shell script guidance.
App Service
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/app-service/deploy-continuous-deployment.md
...n/articles/app-service/deploy-continuous-deployment.md
High Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Missing Linux Example
Summary
The documentation exhibits a mild Windows bias, primarily by referencing 'Windows apps' in the External Git section and not providing equivalent guidance or terminology for Linux-based apps. There is also a lack of explicit Linux or cross-platform command-line examples, and no mention of Linux-specific tools or workflows. The documentation assumes portal-based configuration and does not address parity for Linux users or provide CLI-based alternatives that are common in Linux environments.
Recommendations
- Replace or supplement 'For Windows apps, you can select External Git...' with inclusive language such as 'For apps not directly supported by the Azure portal (including Linux and Windows apps), you can select External Git...'.
- Add explicit examples or notes for Linux-based App Service apps, including any differences in setup or deployment.
- Provide cross-platform command-line examples (e.g., Azure CLI, Bash scripts) alongside portal instructions, especially for enabling/disabling continuous deployment.
- Mention Linux-friendly tools and workflows (such as Bash, SSH, or Linux-based CI/CD runners) where relevant.
- Ensure that screenshots and terminology do not imply Windows exclusivity, and clarify when instructions apply to all platforms.
App Service
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/app-service/deploy-local-git.md
...ocs/blob/main/articles/app-service/deploy-local-git.md
High Priority
View Details →
Detected Bias Types
Powershell Heavy
Windows First
Windows Tools
Missing Linux Example
Summary
The documentation demonstrates a moderate Windows bias. PowerShell is given a dedicated section with detailed steps, and references to 'local PowerShell terminal' are made without Linux shell equivalents. The troubleshooting section includes error messages and resolutions that reference Windows-specific issues (e.g., Node.js native modules lacking Windows binaries). There is no explicit example or guidance for Linux users in sections where PowerShell is mentioned, and the order of presentation often places Windows/PowerShell before Linux/CLI. Additionally, the use of 'PowerShell' as a default local terminal and the lack of explicit Linux shell commands or screenshots further reinforce the bias.
Recommendations
- Add explicit Linux/Bash shell examples and instructions wherever PowerShell is referenced, especially in the 'Create and configure a Git-enabled app' section.
- When referencing a 'local PowerShell terminal', also mention 'Bash' or 'Linux terminal' for parity.
- Ensure that troubleshooting steps and error messages include Linux/macOS-specific guidance where applicable.
- Alternate the order of CLI and PowerShell sections or provide a unified table of commands for both platforms.
- Include screenshots or terminal output from Linux environments, not just Windows.
- Review references to Windows-specific tools or issues (such as Node.js native module errors) and provide Linux/macOS equivalents or notes.
App Service
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/app-service/environment/networking.md
...ob/main/articles/app-service/environment/networking.md
High Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Missing Linux Example
Summary
The documentation page exhibits a Windows-first bias, with several examples and details provided specifically for Windows scenarios (such as Windows Containers and Windows App Service plan SKUs) without equivalent Linux examples or parity. Windows tools and patterns (e.g., Visual Studio remote debugging, Web Deploy) are mentioned explicitly, while Linux-specific deployment or debugging tools are not discussed. There is also a lack of Linux container-specific subnet/IP address calculations or operational notes, and Linux deployment/networking scenarios are only briefly referenced.
Recommendations
- Provide equivalent Linux container subnet/IP address calculation examples, including any differences in IP usage or scaling behavior.
- Include Linux-specific deployment and debugging port requirements (e.g., SSH, SFTP, or other relevant tools) alongside or in place of Windows tools like Visual Studio remote debugging and Web Deploy.
- When listing App Service plan OS/SKU combinations, mention Linux SKUs and their standby/scale behaviors, not just Windows.
- Ensure all examples and operational notes (such as those for Windows Containers) have Linux container counterparts or explicitly state if there are no differences.
- Expand on Linux continuous deployment and network dependency scenarios, referencing relevant documentation and tools.
App Service
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/app-service/deploy-zip.md
...zure-docs/blob/main/articles/app-service/deploy-zip.md
High Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Missing Linux Example
Summary
The documentation exhibits a mild Windows bias. Windows-specific paths (e.g., D:\home\site\wwwroot) are mentioned first, and the Kudu UI (which is not supported on Linux) is described in detail before alternatives for Linux are suggested. The use of 'Advanced Tools' in the Azure portal (Kudu) is a Windows-centric workflow, and Linux-specific instructions or parity for certain features (like the Kudu UI) are absent. Some examples and notes reference Windows paths or behaviors before Linux equivalents, and there is limited explicit guidance for Linux users in these cases.
Recommendations
- When mentioning default paths, list Linux and Windows paths together or alternate the order to avoid always putting Windows first.
- Clearly indicate feature parity or lack thereof for both Windows and Linux at the start of each section, not only in notes after the fact.
- Provide Linux-specific alternatives or workflows (such as using FTP, Azure CLI, or Kudu API) in parallel with Windows/Kudu UI instructions, rather than as afterthoughts.
- Where UI or tool support differs (e.g., Kudu UI not available on Linux), offer a step-by-step Linux-friendly alternative with equal prominence.
- Use neutral language and examples (e.g., use /home/site/wwwroot as the canonical path in code snippets, or show both Windows and Linux paths where relevant).
App Service
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/app-service/environment/app-service-app-service-environment-geo-distributed-scale.md
...-service-app-service-environment-geo-distributed-scale.md
High Priority
View Details →
Detected Bias Types
Powershell Heavy
Missing Linux Example
Windows Tools
Summary
The documentation page exclusively provides Azure PowerShell examples and instructions for configuring Traffic Manager and App Service Environments, with no mention of equivalent CLI (az), Bash, or Linux-native workflows. The only automation and scripting guidance is Windows-centric, and references to 'PowerShell Azure Resource Manager Traffic Manager support' reinforce this bias. There are no Linux or cross-platform command-line examples, nor is there guidance for users who may prefer or require non-Windows tooling.
Recommendations
- Add equivalent Azure CLI (az) examples for all PowerShell commands, as Azure CLI is cross-platform and widely used on Linux and macOS.
- Explicitly mention that all operations can be performed using Azure CLI or REST API, and provide links or references to those resources.
- Where screenshots or instructions reference PowerShell or Windows tools, include parallel examples or notes for Linux/macOS users (e.g., Bash shell, terminal screenshots).
- Review related content and links to ensure Linux-friendly documentation is referenced alongside PowerShell/Windows resources.
- Consider including a section or callout box that highlights cross-platform options for automation and scripting.
App Service
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/app-service/environment/overview-certificates.md
...icles/app-service/environment/overview-certificates.md
High Priority
View Details →
Detected Bias Types
Powershell Heavy
Windows First
Missing Linux Example
Windows Tools
Summary
The documentation page demonstrates a Windows bias by providing only PowerShell commands and examples for certificate management, referencing Windows-specific certificate stores (e.g., Cert:\LocalMachine\Root), and explicitly stating that private client certificates are only supported from custom code in Windows code apps. There are no Linux or cross-platform command-line examples, and Linux scenarios are not addressed.
Recommendations
- Include equivalent Linux/Bash/OpenSSL commands for generating and exporting certificates, alongside the PowerShell examples.
- Clarify support for Linux-based App Service apps, and provide guidance or alternatives for Linux scenarios.
- Reference Linux certificate store locations and how to manage certificates on Linux-based workers, if supported.
- Avoid language that implies Windows is the default or only supported platform unless it is a strict technical limitation; if so, clearly state the limitation and provide alternatives or workarounds for Linux users.
- Add a section or callout explicitly addressing Linux support and any differences in certificate handling.
App Service
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/app-service/getting-started.md
...docs/blob/main/articles/app-service/getting-started.md
High Priority
View Details →
Detected Bias Types
Windows First
Powershell Heavy
Windows Tools
Missing Linux Example
Summary
The documentation page shows evidence of Windows bias, particularly in the .NET/ASP.NET section, where Windows tools such as Visual Studio and Azure PowerShell are listed before cross-platform or Linux-native tools. Some sections (notably .NET) mention Windows-specific tools without equal prominence for Linux alternatives. The 'Next step' callout also defaults to an ASP.NET example, which is typically associated with Windows. In contrast, other stacks (Java, Node.js, PHP) emphasize Linux or cross-platform workflows, but the Python section's quickstart links default to 'windows' tabs, and Linux/WSL/Unix-specific instructions are not always given equal visibility.
Recommendations
- For .NET/ASP.NET, ensure Linux and cross-platform tools (e.g., Visual Studio Code, CLI, Azure CLI) are listed before or alongside Windows-specific tools like Visual Studio and Azure PowerShell.
- Provide explicit Linux/Unix/WSL examples and instructions wherever Windows or PowerShell commands are given, especially in quickstarts and deployment guides.
- In the Python section, ensure quickstart links and tabs default to a neutral or Linux-first experience, or provide parallel instructions for both Windows and Linux.
- Balance the 'Next step' callout by offering options for multiple stacks or explicitly including a Linux-based example.
- Wherever Windows tools or patterns are mentioned, ensure their Linux equivalents are also referenced and easily discoverable.