Scan Details - Linux-first Docs for Azure

193

Pages Scanned

64

Pages Flagged

193

Changed Pages

33.2%

% Pages Flagged

Live Progress

🔴 Connecting...

0%

Phase: discovery

Processing: Initializing...

Activity Feed

00:01:07 Scan started

Scan Information

Started At: 2025-08-15 00:01:07

Finished At: In Progress

Status: in_progress

Target URL: https://github.com/MicrosoftDocs/azure-docs/tree/main/articles

Current Phase: discovery

Problematic Pages

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation page primarily describes deploying an Azure API Management instance via the Azure portal and mentions Azure PowerShell, Azure CLI, and REST API as alternative deployment methods. However, the only explicit command-line tool mentioned first is Azure PowerShell, which is Windows-centric, and there are no concrete CLI or Linux-specific examples provided. The documentation does not provide parity in examples or instructions for Linux users, nor does it highlight cross-platform tools or workflows equally.

Recommendations:

Provide explicit Azure CLI examples alongside or before PowerShell examples, as Azure CLI is cross-platform and widely used on Linux and macOS.
When listing alternative deployment methods, mention Azure CLI before or alongside PowerShell to avoid a Windows-first impression.
Include screenshots or terminal snippets from Linux environments where appropriate, not just the Azure portal UI.
Clarify that all command-line instructions are cross-platform unless otherwise noted, and provide any OS-specific caveats.
Consider a dedicated section or callout for Linux/macOS users to ensure their workflows are equally represented.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias primarily through the exclusive mention of PowerShell in related content and the absence of Linux/CLI examples or references. The only explicit example of connecting virtual networks refers to PowerShell, with no equivalent Azure CLI or Linux-native tooling mentioned. There are no Bash, Linux, or cross-platform command-line instructions or references, and the documentation does not acknowledge Linux or cross-platform users in its guidance or examples.

Recommendations:

Add equivalent Azure CLI examples and references alongside or before PowerShell examples, especially in the 'Related content' section.
Include links to documentation for connecting virtual networks using Azure CLI and/or ARM templates, not just PowerShell.
Wherever PowerShell is mentioned, clarify that Azure CLI and ARM templates are also supported and provide links or examples.
Review the documentation for other subtle Windows-centric terminology or assumptions, and ensure parity for Linux and cross-platform users.
Consider adding a section or note explicitly stating that all operations can be performed from any OS using Azure CLI or the Azure Portal, not just from Windows/PowerShell.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page is largely platform-neutral, focusing on Azure networking concepts and requirements. However, there are several instances where Windows-specific tools, services, or endpoints are referenced without equivalent Linux mentions. Notably, the KMS endpoint section is exclusively about Windows VM activation, and the internal infrastructure section lists endpoints for Windows Update and Windows Defender without Linux equivalents or clarifications. Additionally, a referenced link for connecting VNets uses 'powershell' in its filename, suggesting a Windows-centric example. There are no explicit Linux or cross-platform command examples provided.

Recommendations:

When mentioning Windows-specific requirements (e.g., KMS, Windows Update, Windows Defender), clarify whether there are any equivalent requirements or considerations for Linux VMs, or explicitly state that these are not applicable to Linux.
If providing links or examples for VNet connectivity or configuration, include both PowerShell (Windows) and Azure CLI/Bash (cross-platform/Linux) options, or link to documentation that covers both.
Add a section or notes on Linux VM considerations for API Management in VNets, if any, to ensure parity and clarity for non-Windows users.
Where possible, avoid implying that Windows is the default or only supported platform by using neutral language and providing cross-platform guidance.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation page demonstrates a strong Windows bias: all migration tools and examples focus exclusively on migrating from Windows/IIS environments, with repeated references to PowerShell scripts and Windows-specific tools (e.g., App Service Migration Assistant for Windows, PowerShell scripts for IIS). There is no mention of Linux-based .NET hosting environments (such as Kestrel or Apache/Nginx), nor are there migration paths or tools described for Linux servers. The documentation assumes the source environment is always Windows/IIS, omitting Linux scenarios entirely.

Recommendations:

Add guidance and tooling for migrating .NET apps hosted on Linux servers (e.g., Kestrel, Apache, Nginx) to Azure App Service.
Include Linux-specific migration examples and scripts, such as Bash or shell scripts, alongside PowerShell examples.
Mention and document any Azure App Service migration tools or workflows that support Linux-based .NET apps, or clarify if such support is not available.
Present migration scenarios for both Windows and Linux environments, ensuring parity in documentation structure and detail.
If certain tools are Windows-only, explicitly state this and provide alternative recommendations for Linux users.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page shows subtle Windows bias by referencing Windows-specific tools (such as web.config and iisnode) without providing equivalent Linux alternatives or explanations. Some configuration and troubleshooting guidance assumes a Windows-based environment, and Linux-specific instructions are either missing or mentioned only as an aside.

Recommendations:

For features like auto-healing, provide Linux-native configuration options (e.g., app settings, environment variables, or Linux-specific config files) alongside web.config guidance.
When referencing iisnode or web.config for Node.js apps, include information about how to configure these settings in Linux containers or App Service for Linux, such as using PM2 or environment variables.
Ensure that all examples and troubleshooting steps are presented for both Windows and Linux environments, or clarify when a feature is Windows-only.
Where Windows tools or patterns are mentioned, explicitly provide Linux equivalents and place them with equal prominence in the documentation.
Audit the documentation for other implicit Windows assumptions and address them to ensure Linux users have clear, actionable guidance.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation demonstrates a mild Windows bias. While both Windows and Linux are mentioned as supported platforms, and Azure CLI examples (which are cross-platform) are provided, there is a consistent pattern of presenting Windows-related information and tools first. For example, the SKU availability section lists 'Windows' before 'Linux', and the automation section provides Azure PowerShell (a Windows-centric tool) as a primary scripting option, without mentioning Bash or Linux shell scripting. There are no Linux-specific command-line or scripting examples beyond the Azure CLI, and the PowerShell example is not paralleled with a Linux shell script.

Recommendations:

Present Linux and Windows options in parallel, or alternate which is listed first to avoid implicit prioritization.
When providing automation examples, include both Azure PowerShell and Bash/shell script examples to ensure parity for Linux users.
Where screenshots or portal steps are shown, note any differences for Linux-based App Service plans if applicable.
Explicitly state that Azure CLI commands are cross-platform and suitable for both Windows and Linux users.
Consider adding a section or callout for Linux users, highlighting any platform-specific considerations or best practices.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation shows a mild Windows bias. In several places, Windows is mentioned before Linux (e.g., in availability descriptions and SKU checks). Both Azure CLI and PowerShell scripting are covered, but PowerShell (a Windows-centric tool) is given its own section, while no Linux shell scripting (e.g., Bash) or automation examples are provided. The portal instructions and screenshots are Windows-oriented, and there is no mention of Linux-specific tools or workflows beyond a single CLI flag.

Recommendations:

Provide Linux shell (Bash) scripting examples for automation, not just Azure CLI and PowerShell.
Ensure Linux is mentioned alongside Windows, not after, in all availability and feature descriptions.
Add guidance or screenshots for Linux users where portal UI or tooling may differ.
Clarify that Azure CLI commands are cross-platform and can be run on Linux, macOS, and Windows.
If referencing PowerShell, consider also referencing Bash or other common Linux scripting environments for parity.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation generally provides both Windows and Linux instructions, but there is a noticeable Windows-first bias. Windows instructions and tools (such as the GUI and PowerShell commands) are often presented before Linux equivalents, and some troubleshooting steps only provide Windows-specific commands (e.g., PowerShell's Test-NetConnection) without Linux alternatives. The Hybrid Connection Manager GUI is only available on Windows, and this is clearly stated, but the documentation could do more to offer parity in troubleshooting and examples for Linux users.

Recommendations:

Present Windows and Linux instructions/examples in parallel or with equal prominence, rather than listing Windows first by default.
For troubleshooting steps, provide equivalent Linux commands (e.g., suggest using 'nc' or 'telnet' for TCP connectivity tests instead of only PowerShell's Test-NetConnection).
Where GUI tools are Windows-only, offer enhanced CLI or alternative Linux workflows and highlight them as first-class options.
In sections where only Windows tools or patterns are mentioned (such as service management or firewall configuration), add Linux equivalents (e.g., systemctl for service management, ufw/iptables for firewall).
Ensure all code snippets and walkthroughs have both Windows and Linux versions where applicable.
Consider adding a summary table at the start of each section indicating OS support and tool availability.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias primarily in the section addressing Azure Traffic Manager endpoints, where only a PowerShell script is provided to identify non-Azure endpoints. There are no equivalent Bash, Azure CLI, or cross-platform alternatives offered. Throughout the page, when command-line guidance is given, REST API and Azure CLI references are present, but in the one scenario requiring scripting, only PowerShell is mentioned, with no Linux/macOS-compatible example. This may disadvantage users on Linux or macOS who do not have access to PowerShell or prefer Bash scripting.

Recommendations:

Provide a Bash or Azure CLI script alternative to the PowerShell script for identifying non-Azure Traffic Manager endpoints, or at least mention how Linux/macOS users can achieve the same result.
When referencing scripts or automation, offer both Windows (PowerShell) and Linux/macOS (Bash/CLI) examples to ensure parity.
Explicitly state if a solution is Windows-only and provide guidance for non-Windows users.
Consider linking to cross-platform tools or scripts, or provide guidance on running PowerShell Core on Linux/macOS if no alternative exists.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation exclusively discusses discovery of ASP.NET web apps on IIS web servers within VMware environments, which are all Windows-centric technologies. There is no mention of Linux-based web servers (such as Apache or Nginx), nor are there examples or guidance for discovering .NET apps hosted on Linux. All references, capabilities, and linked resources focus on Windows tools and patterns.

Recommendations:

Include guidance and examples for discovering .NET web apps hosted on Linux servers (e.g., Kestrel, Apache, Nginx).
Mention whether Azure Migrate supports Linux-based .NET app discovery, and if not, clarify this limitation.
Add parity in documentation by providing Linux-specific instructions, tooling, and troubleshooting steps.
Reference Linux migration resources and tools alongside Windows/IIS examples.
Explicitly state platform support and any differences in discovery capabilities between Windows and Linux environments.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ windows_first

Summary:

The documentation page demonstrates a strong bias towards Windows and PowerShell usage. All CLI-based restoration instructions and examples are provided exclusively using PowerShell cmdlets from the Az PowerShell module, with no mention of Azure CLI, Bash, or cross-platform scripting alternatives. The documentation assumes the use of Windows-centric tools and patterns, and does not provide parity for Linux or macOS users who may prefer or require non-PowerShell solutions.

Recommendations:

Add equivalent Azure CLI (az) command examples for all PowerShell cmdlets, as Azure CLI is cross-platform and widely used on Linux and macOS.
Explicitly mention that PowerShell Core is available cross-platform, but also provide Bash or shell script examples where appropriate.
Include notes or sections for Linux/macOS users, clarifying how to perform the same tasks without relying on Windows-specific tools.
Ensure that any references to tools or workflows are not Windows-centric by default, and present cross-platform options with equal prominence.
Consider reordering sections so that cross-platform solutions (such as Azure CLI) are presented before or alongside PowerShell examples.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation is heavily focused on Windows environments, specifically Azure App Service on Windows with iisnode. All configuration and troubleshooting steps reference Windows-specific tools, paths (e.g., node.exe, web.config, named pipes, Win32 error codes), and workflows (Kudu, PowerShell, CMD). There are no Linux equivalents or examples, and Linux-based deployment or troubleshooting is not mentioned. Windows terminology and tools are used exclusively or introduced first throughout the document.

Recommendations:

Add equivalent sections or links for Linux-based Azure App Service (e.g., using PM2, NGINX, or other process managers instead of iisnode/IIS).
Provide Linux-specific troubleshooting steps, including log file locations, process management, and error handling.
Include examples using Bash or Linux shell commands alongside or instead of PowerShell/CMD.
Reference Linux file paths and configuration files where appropriate (e.g., /home/site/wwwroot, /var/log).
Clarify at the start that the guide is Windows-specific, and link to a Linux-focused guide if available.
Where possible, generalize best practices to be cross-platform and call out platform-specific differences in dedicated sections.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation is heavily oriented toward Windows and Visual Studio on Windows. All instructions, screenshots, and tool references assume the user is on Windows, using Visual Studio, and deploying to Azure App Service (Windows). There are no examples or instructions for Linux users, command-line alternatives, or cross-platform development environments. PowerShell and Windows-specific tools (e.g., Package Manager Console, SQL Server Object Explorer) are used exclusively, with no mention of Bash, Azure CLI, or VS Code.

Recommendations:

Add parallel instructions and screenshots for Linux/macOS users, including using VS Code or JetBrains Rider as alternative IDEs.
Include Azure CLI and Bash command examples for all steps currently shown with PowerShell or Visual Studio UI.
Provide guidance for deploying to Azure App Service (Linux) in addition to (Windows), and explain differences if any.
Reference cross-platform tools (e.g., Azure Data Studio instead of SQL Server Object Explorer) for database management.
Clarify which steps are Windows-specific and provide alternatives for non-Windows environments.
Ensure all code/package installation steps have cross-platform equivalents (e.g., dotnet CLI for package management).

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by providing server-level authorization instructions exclusively for Windows apps using IIS and web.config, with no equivalent Linux example. The section explicitly states that Linux apps cannot use this method and does not offer alternative guidance for Linux users. Additionally, the use of Windows-specific patterns (IIS, web.config) is presented before any cross-platform or Linux-compatible approaches.

Recommendations:

Provide equivalent Linux guidance for server-level authorization, such as using .htaccess for Apache, NGINX configuration, or middleware-based authorization in common Linux web stacks.
Include explicit examples and configuration steps for Linux-based App Service environments.
Reorganize the documentation to present cross-platform or Linux-compatible solutions alongside or before Windows-specific instructions.
Clarify which features or instructions are platform-specific and always offer alternatives where possible.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation page primarily provides examples and code snippets in C#/.NET, which are most commonly associated with Windows development. Framework-specific alternatives are listed with .NET/ASP.NET first and in greatest detail, while Linux-centric languages and frameworks (such as Python, Node.js, or shell scripting) are not mentioned or exemplified. There are no examples or references to Linux command-line tools, shell environments, or Linux-specific patterns for accessing headers or decoding Base64/JSON. The PHP and Java mentions are brief and lack code samples, and there are no examples for Python, Node.js, or other popular cross-platform stacks.

Recommendations:

Add code examples for accessing and decoding the X-MS-CLIENT-PRINCIPAL header in popular Linux-friendly languages such as Python (Flask/Django), Node.js (Express), and Go.
Include shell command-line examples (e.g., using curl, jq, base64) for decoding the header, which would be useful for Linux users.
Balance the framework-specific alternatives section by providing equal detail and code samples for non-Windows stacks.
Explicitly mention that the process is platform-agnostic and provide guidance for both Windows and Linux environments.
Consider the order of presentation: do not always list Windows/.NET first; alternate or group by popularity or platform neutrality.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates some Windows bias, primarily through the exclusive mention of Windows-specific deployment tools (such as Web Deploy and MSBuild), and by referencing Visual Studio deployment without mentioning cross-platform alternatives. There are no explicit Linux or macOS-specific deployment tool examples, and the documentation does not provide parity in discussing Linux-native tools or workflows. While Azure CLI examples are cross-platform, the overall framing and tool references are Windows-centric.

Recommendations:

Include examples or references for deploying from Linux/macOS environments, such as using SCP/SFTP, rsync, or Linux-native FTP clients.
Mention and provide examples for cross-platform deployment tools (e.g., VS Code with Azure extensions, Git, or third-party CI/CD tools) alongside Visual Studio and MSBuild.
Clarify that Azure CLI commands can be run from any OS, and provide explicit instructions or screenshots for Linux/macOS terminals where appropriate.
When referencing 'Web Deploy' and 'MSBuild', note their Windows-specific nature and suggest Linux/macOS alternatives or workarounds.
In the deployment method table, add a column or notes indicating OS compatibility for each method, especially for those that are Windows-only.
Provide troubleshooting or confirmation steps using Linux/macOS command-line tools (e.g., curl, git, lftp) in addition to or instead of Windows tools.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates several forms of Windows bias. While it covers both Azure CLI and PowerShell, PowerShell (a Windows-centric tool) is given equal prominence, and some advanced/bulk operations are only possible in PowerShell or are not possible at all outside it. Several features (default documents, virtual directory mapping, handler mappings) are explicitly Windows-only, but this is not always clearly stated at the top of those sections. Examples for Linux-specific workflows or tools are minimal or absent, and Windows-specific paths and patterns (e.g., D:\home, site\wwwroot) are used throughout. The documentation often references Windows tools and patterns before or instead of Linux equivalents.

Recommendations:

Clearly indicate at the beginning of each section which features are Windows-only, and provide Linux alternatives or workarounds where possible.
Where PowerShell is used for advanced/bulk operations, provide equivalent Bash or cross-platform scripting examples, or state explicitly if not possible.
Avoid using Windows-specific paths (e.g., D:\home, site\wwwroot) in generic examples; provide Linux path equivalents or clarify when these are Windows-only.
For features not available on Linux (e.g., handler mappings, virtual directories), suggest alternative approaches for Linux users or link to relevant Linux/container documentation.
Ensure that Linux and container workflows are given equal prominence, not just mentioned in passing or as exceptions.
Where CLI commands have platform-specific caveats (e.g., quoting, escape characters), provide both Windows (PowerShell/CMD) and Linux (Bash) examples.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a moderate Windows bias. Windows-specific content and examples are often presented first or in more detail, especially regarding base images, persistent storage, and advanced configuration (e.g., customizing memory/CPU, health ping, machine key injection). PowerShell examples are consistently provided alongside Bash, but not vice versa for Linux-specific commands. Some advanced configuration sections (e.g., customizing memory/CPU, health ping) are only described for Windows containers, with no Linux equivalent or guidance. Windows tools and patterns (e.g., Kudu, PowerShell, Windows directory paths) are referenced more prominently or exclusively in some sections.

Recommendations:

Ensure all advanced configuration sections (e.g., memory/CPU limits, health ping behavior) include Linux parity or explicitly state if not supported on Linux.
When providing command-line examples, always include both Bash (for Linux) and PowerShell (for Windows) where applicable, and clarify which OS each applies to.
Present Windows and Linux content in parallel or with equal prominence, rather than consistently leading with Windows.
Where Windows-specific tools or concepts are mentioned (e.g., Kudu, C:\home), ensure Linux equivalents (e.g., /home, SSH, Linux logging paths) are equally described.
For sections that are only relevant to Windows (e.g., machine key injection), clearly label them as such and provide Linux-specific security/configuration advice where possible.
Review for missing Linux examples or guidance, especially in sections about advanced configuration, diagnostics, and persistent storage.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias by referencing Azure Storage Explorer with a direct link to the Windows tab for generating SAS tokens, and does not mention or provide alternatives for Linux users. There are no Linux-specific instructions or examples for uploading files or generating SAS tokens, and the only tool mentioned for these tasks is Azure Storage Explorer, which is often associated with Windows environments. All command-line examples use Azure CLI, which is cross-platform, but the file upload and SAS generation steps lack Linux parity.

Recommendations:

Include instructions or examples for uploading files and generating SAS tokens using Azure CLI or Azure Portal, which are platform-agnostic.
Explicitly mention that Azure Storage Explorer is available on Linux and macOS, or provide alternative tools/commands for Linux users.
Avoid linking directly to the Windows tab in documentation references; instead, provide a general link or mention all supported platforms.
Add a section or note for Linux users on how to perform the same tasks without relying on Windows-centric tools.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation exhibits a clear Windows bias: it states that gateway-required virtual network integration only works for Windows plans and explicitly excludes Linux apps. All troubleshooting and connectivity examples use Windows-specific tools (e.g., PowerShell's Test-NetConnection, netstat -aon), with no mention of Linux equivalents or guidance for Linux users. There are no Linux command-line examples or references, and the documentation does not address how Linux users should approach similar troubleshooting or integration tasks.

Recommendations:

Where possible, provide Linux equivalents for all troubleshooting and connectivity commands (e.g., use 'nc' or 'telnet' for TCP checks, 'ss' or 'netstat' for port listening).
Explicitly state early in the document that gateway-required integration is not supported for Linux apps, and offer clear alternatives or guidance for Linux users (e.g., recommend regional VNet integration for Linux).
When referencing tools or commands, present both Windows and Linux options side by side to ensure parity.
Add a section or callout for Linux users explaining their options and any differences in supported features.
If certain features are Windows-only, provide links to Linux-supported alternatives and migration guidance.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation demonstrates a mild Windows bias by presenting Windows instructions and tools (such as Kudu, CMD, and PowerShell) before Linux equivalents, and by referencing Visual Studio and Windows-specific deployment patterns more prominently. While Linux-specific instructions and examples are present and reasonably thorough, Windows concepts and tools are often introduced first or in more detail, and the overall narrative assumes familiarity with Windows-centric workflows.

Recommendations:

Ensure Linux and Windows instructions/examples are presented in parallel or with equal prominence, rather than Windows-first.
When referencing tools like Kudu, CMD, or PowerShell, provide equivalent Linux-native alternatives (e.g., SSH, Bash shell, or Linux-based diagnostic tools) and mention them together.
Balance mentions of Visual Studio with cross-platform tools (e.g., VS Code, CLI-based workflows) to avoid assuming a Windows development environment.
Where possible, provide side-by-side code blocks or tabs for both Windows and Linux commands, especially for common tasks like viewing logs, setting environment variables, or accessing the console.
Expand on Linux-native troubleshooting and diagnostic workflows to match the detail given for Windows/Kudu/PowerShell.
Review the order of sections and examples to avoid always leading with Windows; alternate or group by platform as appropriate.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation page demonstrates a clear Windows bias. It assumes the use of Windows-based App Service instances, referencing Windows file paths, CMD/PowerShell consoles, and Visual Studio as the primary tooling. There are no Linux-specific examples or instructions, and Linux-based deployment or configuration scenarios are not addressed. The documentation does not mention or show how to perform equivalent tasks on Linux App Service plans or containers.

Recommendations:

Add parallel instructions and examples for Linux-based App Service plans, including how to check .NET runtime versions and access diagnostic tools in Linux environments.
Include Linux shell (bash) commands and file paths where appropriate, alongside Windows CMD/PowerShell examples.
Clarify when instructions are Windows-specific and provide links or sections for Linux users.
Reference cross-platform tools (such as Azure CLI, Kudu SSH, or VS Code) equally, and avoid assuming Visual Studio or Windows-only workflows.
Explicitly mention differences in environment variable access, file system layout, and diagnostic log access between Windows and Linux App Service environments.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation generally provides parity between Linux and Windows for most APM configuration steps, but there are subtle signs of Windows bias. Windows-specific tools (like the Kudu console) are mentioned for Windows scenarios, while Linux uses SSH, but the documentation does not always provide equal detail or guidance for Linux-specific workflows (e.g., Kudu is not mentioned for Linux, and SSH is referenced for both platforms in some places). In the Application Insights section, the Windows app settings include an extra setting (XDT_MicrosoftApplicationInsights_Java=1) not explained for Linux. The ordering of tabs and examples sometimes puts Windows first. There are also references to PowerShell/Windows patterns (e.g., Kudu) without Linux equivalents or explanations.

Recommendations:

Ensure that any Windows-specific tools (like Kudu) have Linux equivalents mentioned, or clarify when a tool is Windows-only.
Provide equal detail for Linux workflows, including step-by-step instructions for common Linux tools (e.g., using SCP/SFTP for file upload, or Linux-native consoles).
Explain any differences in app settings between Windows and Linux (e.g., why XDT_MicrosoftApplicationInsights_Java=1 is only for Windows).
When listing tabbed examples, alternate the order or default to Linux-first to avoid implicit Windows prioritization.
Avoid referencing PowerShell or Windows-specific patterns unless a Linux equivalent is also provided.
Review for any missing Linux examples or explanations, especially for advanced configuration or troubleshooting.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation provides both Linux and Windows instructions for configuring Tomcat data sources, but the Windows section is notably more detailed, featuring extensive PowerShell scripting and Windows-specific file paths and tools. Windows configuration steps are described with more granularity, including custom startup scripts and PowerShell automation, whereas Linux instructions are more concise and rely on shell scripting. Additionally, Windows tools (PowerShell, Windows paths) are featured prominently, and in some sections, Windows instructions appear before or are more elaborate than their Linux counterparts.

Recommendations:

Ensure Linux and Windows instructions are equally detailed, providing parity in step-by-step guidance and troubleshooting.
Where PowerShell scripts are provided for Windows, offer equivalent Bash scripts for Linux, with similar explanations and comments.
Avoid assuming familiarity with Windows tools (e.g., PowerShell) without offering Linux alternatives (e.g., Bash, shell scripting) in parallel.
Present Linux and Windows instructions side-by-side or in the same order to avoid implicit prioritization.
Highlight any platform-specific limitations or differences explicitly, so users on both platforms understand the context.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation generally provides parity between Linux and Windows, but there are subtle signs of Windows bias. In several sections, Windows examples or instructions are presented before Linux equivalents (windows_first). Some advanced troubleshooting and process management instructions for Windows rely on Kudu/Advanced Tools, which are Windows-specific (windows_tools). There are also areas where PowerShell or Windows-centric tools are referenced more prominently (powershell_heavy). In a few cases, Linux-specific details are less comprehensive or are missing compared to Windows (missing_linux_example).

Recommendations:

Ensure that Linux and Windows instructions are always presented in parallel, or alternate which comes first to avoid implicit prioritization.
Where Windows-specific tools (like Kudu/Advanced Tools) are referenced, provide equivalent Linux-native instructions or clarify if a feature is not available.
Avoid using PowerShell or Windows command-line tools as the default or only example; always provide Bash/Azure CLI/Linux-native equivalents.
Audit all sections for completeness of Linux examples, especially for advanced scenarios (e.g., process management, log analysis, deployment troubleshooting).
Highlight Linux-specific troubleshooting and customization options, such as using SSH, Linux package managers, and native file paths.
Where a feature is only available on one platform, clearly state this and provide workarounds or alternatives for the other platform.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation demonstrates a mild Windows bias. Windows-specific tools and patterns (such as IISNode and web.config) are described in detail, and Windows instructions or pivots are often presented before Linux equivalents. There is also a reference to using PowerShell for Application Insights instrumentation, but no equivalent Bash or Linux CLI example. Some sections (e.g., troubleshooting, diagnostic logs) provide more detailed or prominent guidance for Windows scenarios.

Recommendations:

Ensure Linux and Windows instructions are presented with equal prominence, alternating which platform appears first in each section or using a neutral introduction.
Where PowerShell or Windows-specific tooling is referenced (e.g., for Application Insights), provide equivalent Bash or Linux CLI examples.
Expand Linux-specific troubleshooting guidance to match the detail provided for Windows (e.g., common issues with startup commands, permissions, or container configuration).
Where Windows-specific files (like web.config) are discussed, add parallel notes for Linux (e.g., startup scripts, Dockerfile, or configuration best practices).
Review all sections for parity in depth and clarity between Windows and Linux pivots, ensuring that neither platform is treated as the default.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation is structured with a clear separation between Windows and Linux instructions using platform pivots. However, several sections (notably 'Run Composer', 'Run Bower, Gulp, or Grunt') provide detailed, step-by-step deployment automation examples only for Windows (using KuduScript and npm), with no equivalent Linux guidance. Some Windows-specific tools and paths (e.g., KuduScript, d:\ paths) are mentioned, and in a few cases, Windows instructions or tools are described before Linux equivalents, indicating a 'windows_first' bias. There are also areas where Linux users are left to infer or research their own solutions, especially regarding custom deployment scripts and automation.

Recommendations:

Provide equivalent, detailed Linux examples for deployment automation tasks (e.g., running Composer, Bower, Gulp, Grunt) rather than only describing the Windows/KuduScript approach.
Where Windows-specific tools (like KuduScript) are mentioned, clarify their availability or alternatives for Linux users, or provide Linux-native instructions.
Ensure that both Windows and Linux pivots receive equal depth of explanation and example code, especially for common developer workflows.
Avoid always presenting Windows instructions or tools first; consider alternating or presenting both platforms in parallel where possible.
For Linux, include more practical examples for customizing deployment scripts, running build tools, and managing extensions, to match the detail given for Windows.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation provides command-line examples for Azure CLI and Azure PowerShell, but does not include Linux-native or cross-platform shell (e.g., Bash) examples beyond Azure CLI. PowerShell is featured as a distinct section, and the FAQ references PowerShell specifically. There are no explicit Linux-specific tools or workflows mentioned, and no guidance for Linux certificate management outside of Azure CLI. The documentation does not mention or address Linux certificate stores, OpenSSL, or other common Linux patterns, and the ordering of examples places PowerShell after CLI but before any Linux-native approach (which is absent).

Recommendations:

Add explicit Bash or Linux-native examples for certificate export and management, especially for scenarios outside Azure CLI.
Include references to common Linux tools (e.g., OpenSSL) for handling .pfx files after export, such as converting or installing certificates.
In the FAQ, address Linux users by providing troubleshooting steps relevant to Linux environments (e.g., how to check certificate status or export using Bash/OpenSSL).
Ensure parity in example ordering: if PowerShell is included, also include Bash or Linux shell examples, and consider presenting CLI/Bash before PowerShell.
Mention any OS-specific considerations for importing/exporting certificates, such as differences in certificate stores or required tools on Linux.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page exhibits a mild Windows bias, particularly in the automation section. PowerShell is featured explicitly with a code sample, while the Azure CLI is only referenced via a link without an inline example. There is no mention of Linux-specific tools or shell scripting, and the PowerShell example appears before any Linux/CLI equivalent. The rest of the documentation is mostly platform-neutral, but the automation section lacks parity for Linux users.

Recommendations:

Provide inline Azure CLI examples alongside PowerShell, not just as links, to ensure Linux users have immediate guidance.
Include Bash or shell script examples where automation is discussed, or at least reference their availability.
When listing automation options, present Azure CLI (cross-platform) examples before or alongside PowerShell to avoid a Windows-first impression.
Explicitly mention that both CLI and PowerShell approaches are supported on all platforms, and clarify any platform-specific prerequisites if they exist.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows-first bias by providing detailed, code-rich examples for Windows environments (including both C# and Java with Windows certificate store usage) before mentioning Linux. Windows-specific tools and patterns (such as the Windows certificate store and environment variables) are described in depth, while Linux examples are less prominent, less detailed, and often deferred to external documentation. Non-Windows languages (Node.js, PHP, Python) are not given direct examples, and Linux-specific guidance is less comprehensive.

Recommendations:

Provide Linux examples alongside Windows examples, not after them or as an afterthought.
Include code samples for Linux environments in multiple languages (e.g., Python, Node.js, Java), not just C#.
Offer equal detail for Linux certificate handling, including how to load certificates in common Linux programming environments.
Avoid referring readers to external documentation for Linux/non-Windows languages when Windows examples are provided inline.
Explicitly mention Linux equivalents for all Windows-specific tools and patterns, such as certificate stores and environment variables.
Structure the documentation so that Linux and Windows guidance are presented in parallel sections or tabs, ensuring parity.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation exhibits a moderate Windows bias. PowerShell is presented alongside Azure CLI for automation, but there are references to Windows-specific tools (IIS, Certreq.exe) for certificate export, and instructions for exporting certificates from Windows are more detailed than for Linux. There is no explicit mention of Linux-based workflows or tools (such as certbot or Linux certificate stores), and Windows patterns (IIS, Certreq.exe) are mentioned before or instead of Linux equivalents. The FAQ also references Windows container support specifically, without clarifying Linux support.

Recommendations:

Add explicit Linux-based examples for certificate generation and export, such as using OpenSSL on Linux, and mention Linux certificate stores where relevant.
When referencing Windows tools (IIS, Certreq.exe), provide equivalent Linux instructions (e.g., using OpenSSL, certbot, or other common Linux utilities).
Ensure parity in automation examples by including Bash scripts or Linux shell commands alongside PowerShell.
Clarify OS-specific limitations or capabilities, especially in the FAQ, to indicate Linux support or lack thereof.
Avoid presenting Windows tools or patterns before Linux equivalents; instead, present both together or in parallel tabs.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation provides both Azure CLI and Azure PowerShell instructions for configuring virtual network integration. However, it gives a detailed, step-by-step PowerShell workflow (which is Windows-centric), while the CLI section is brief and lacks equivalent depth. There are no Linux shell or Bash-specific examples, and the PowerShell section is more comprehensive, indicating a bias toward Windows tools and workflows.

Recommendations:

Expand the Azure CLI section to provide step-by-step instructions equivalent to the PowerShell section, including parameter preparation, subnet delegation checks, and integration steps.
Include Bash or shell scripting examples for Linux users, especially for tasks like checking subnet delegation and setting resource context.
Clearly state that both Azure CLI and PowerShell are cross-platform, but provide explicit Linux/Bash examples to ensure parity.
Avoid assuming PowerShell as the default advanced scripting tool; balance with Bash or other Linux-native tools where possible.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by prioritizing Windows-specific tools (PowerShell, Visual Studio) and workflows. PowerShell is given a dedicated row, and Visual Studio (a Windows-centric IDE) is described in detail, with multiple references. There is no mention of Linux-native deployment tools or workflows (such as Bash scripts, SCP, rsync, or Linux package managers), nor are there any Linux-specific examples or parity for Linux users. Visual Studio Code is mentioned, but only in the context of .NET and GitHub, not as a cross-platform deployment tool. The documentation does not provide Linux command-line examples or highlight Linux deployment scenarios.

Recommendations:

Add Linux-native deployment examples, such as using Bash scripts, SCP, rsync, or SFTP for deploying to Azure App Service.
Include references to Linux package managers or automation tools (e.g., Ansible, Chef, Puppet) for deployment.
Provide parity in documentation for Linux users by including step-by-step guides or examples using common Linux shells and tools.
Highlight cross-platform tools (such as Azure CLI and Visual Studio Code) more prominently, with explicit Linux usage instructions and screenshots.
Balance the coverage of Visual Studio and PowerShell with equivalent open-source or Linux-friendly tools and workflows.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation demonstrates a Windows bias in several ways: Windows-specific deployment methods (Web Deploy) are highlighted, with explicit instructions and troubleshooting for Windows agents, while Linux alternatives are not equally covered. Some examples and error messages assume or require Windows agents, and there is a lack of parity in Linux-specific deployment guidance. Windows tools and patterns (such as IIS, Web Deploy, and references to Windows agent pools) are mentioned without Linux equivalents or alternatives.

Recommendations:

Provide equivalent Linux-based deployment examples, especially for scenarios where only Windows/Web Deploy is discussed.
Explicitly state when a feature is Windows-only and suggest Linux alternatives (e.g., using ZIP deploy, FTP, or Kudu REST API for Linux agents).
Include troubleshooting steps and error messages relevant to Linux agents, not just Windows.
Balance the order of presentation so that Linux and Windows options are presented equally, or clarify platform-specific limitations up front.
Where Windows tools (like Web Deploy or IIS) are mentioned, provide context or links for Linux users on how to achieve similar results.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a subtle Windows bias by referencing Windows-specific tools (such as WebDeploy and Kudu's Windows process) before or more prominently than their Linux equivalents. There is a lack of explicit Linux command-line examples (e.g., SCP, SFTP, rsync) for deployment, and the documentation does not provide parity in describing Linux-native workflows or tools. The Kudu section describes its operation on Windows in more detail than on Linux. WebDeploy, a Windows-centric tool, is mentioned without Linux alternatives. No Linux shell or cross-platform deployment examples are provided outside of the GitHub Actions YAML, which is generic.

Recommendations:

Add explicit Linux-native deployment examples (e.g., using SCP, SFTP, rsync, or Azure CLI from a Linux shell) alongside or before Windows tools.
Clarify Kudu's operation on both Windows and Linux App Service plans, giving equal detail for both.
When mentioning WebDeploy (a Windows tool), also mention and provide guidance for Linux users (e.g., using FTP, Azure CLI, or other cross-platform tools).
Provide sample deployment commands/scripts for both PowerShell/Windows CMD and Bash/Linux shell.
Review the order of tool presentation to avoid always listing Windows tools or patterns first.
Where possible, use neutral, cross-platform language and examples, or explicitly call out differences and options for both Windows and Linux users.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation is heavily focused on deploying Windows containers, with all examples, YAML snippets, and variable defaults set for Windows (e.g., 'windows-latest' VM image). There are no Linux container examples, nor any mention of how to adapt the process for Linux-based applications or App Service for Linux. The App Service deploy task is configured specifically for 'Web App for Containers (Windows)', and the sample Docker image is a Windows/.NET Framework image. Linux tools, images, or deployment targets are not discussed or referenced.

Recommendations:

Add parallel examples and instructions for deploying Linux containers, including YAML snippets using 'ubuntu-latest' or other Linux VM images.
Explicitly mention how to adapt the pipeline for Linux-based applications and App Service for Linux.
Include a section or callout noting the differences between deploying to Windows vs. Linux App Service, with links to relevant documentation.
Provide sample Dockerfiles and image references for Linux-based applications (e.g., ASP.NET Core on Linux).
Ensure variable names and task configurations are not hardcoded to Windows unless necessary, and show how to parameterize for both OS types.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates subtle Windows bias. The 'External Git' section explicitly states it is for 'Windows apps', with no mention of Linux or cross-platform scenarios. There are no examples or guidance for Linux-based deployments, nor are Linux-specific tools or workflows referenced. The documentation assumes a Windows-centric context in some areas and omits parity for Linux users.

Recommendations:

Clarify whether 'External Git' is supported for Linux apps, and if so, provide explicit instructions or examples for Linux-based deployments.
Wherever a feature or workflow is described as 'for Windows apps', add a corresponding note or section for Linux apps, or state clearly if not supported.
Include Linux-specific or cross-platform examples and references, especially in sections discussing manual deployment or advanced configuration.
Review screenshots and UI references to ensure they are not Windows-specific, or provide Linux equivalents if the portal experience differs.
Audit related links and references to ensure they include Linux-relevant documentation and troubleshooting resources.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias by prioritizing Windows-centric tools and workflows. PowerShell is given equal prominence to Azure CLI, and Windows tools such as WinSCP and Visual Studio are mentioned before or instead of Linux alternatives. There are no explicit Linux command-line FTP client examples, and the documentation lacks references to common Linux tools or workflows for FTP/S deployment.

Recommendations:

Add explicit Linux command-line FTP/S examples (e.g., using lftp, curl, or ftp commands) alongside or before PowerShell examples.
Include Linux-native FTP/S clients (e.g., FileZilla, lftp, gFTP) in the list of recommended FTP/S clients.
When listing tools, alternate or balance the order (e.g., mention Visual Studio and FileZilla together, not just Windows tools first).
Provide sample shell scripts or CLI commands for Linux users to automate FTP/S deployment.
Clarify that Azure CLI commands are cross-platform and can be used on Linux, macOS, and Windows.
Add troubleshooting steps or notes relevant to Linux environments (e.g., firewall configuration, passive mode setup).

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a moderate Windows bias. PowerShell is featured prominently, with a dedicated section and detailed steps, while Linux-specific shell or Bash examples are limited. The troubleshooting section references Windows-specific errors (e.g., native modules lacking Windows binaries), and the PowerShell workflow is described in detail. There is no explicit Linux or macOS terminal walkthrough for the same tasks, and the use of PowerShell is presented before or alongside CLI/portal options, but not after a Linux/Bash example. Some instructions (e.g., 'local terminal') are ambiguous but default to Windows/PowerShell context.

Recommendations:

Add explicit Linux/macOS terminal (Bash) walkthroughs for all steps, especially for creating/configuring the app and setting deployment branch.
Ensure that CLI examples are presented before PowerShell, or provide parallel Linux and Windows instructions side-by-side.
Include troubleshooting notes for common Linux/macOS issues (e.g., permissions, case sensitivity, SSH agent problems) alongside Windows-specific notes.
Clarify when instructions are OS-agnostic and when they are specific to Windows or Linux, and use neutral terms like 'terminal' instead of 'PowerShell terminal' unless necessary.
Reference Linux tools and patterns (e.g., Bash, zsh, Linux file paths) where appropriate, and avoid assuming Windows as the default environment.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page exhibits a Windows-first bias by referencing Windows file paths (e.g., D:\home\site\wwwroot) before Linux equivalents, using backslash path separators, and describing deployment behaviors primarily in Windows terms. There is a lack of explicit Linux/macOS command-line examples, and some instructions (such as manual file placement) only mention Windows-style paths. The documentation also refers to Windows-centric tools and patterns (e.g., backslash paths, drive letters) without always providing Linux alternatives or parity.

Recommendations:

Present Linux and Windows file paths together in all relevant sections (e.g., D:\home\site\wwwroot (Windows) and /home/site/wwwroot (Linux)).
Include Linux/macOS-specific command-line examples and clarify any differences in behavior or file locations.
Use forward slashes in file paths or provide both path formats where appropriate.
Explicitly mention when instructions or behaviors differ between Windows and Linux App Service environments.
Add troubleshooting notes or caveats for Linux users where necessary (e.g., file permissions, directory structure).
Ensure parity in tool recommendations, avoiding exclusive references to Windows tools or patterns.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation demonstrates a moderate Windows bias. While it provides both Azure CLI and Azure PowerShell examples for all operations, it frequently references Windows-centric tools and patterns (such as PowerShell and Web.config), and sometimes presents PowerShell examples before CLI. There is also a reliance on Windows-specific configuration (e.g., Web.config, applicationInitialization), and troubleshooting steps reference Windows file paths (D:\home\LogFiles\eventlog.xml). There are no explicit Linux shell or scripting examples, and some features (like auto swap) are noted as unsupported on Linux, but without Linux-specific alternatives or guidance.

Recommendations:

Add explicit Linux shell (bash) examples where relevant, especially for scripting or automation scenarios.
When referencing configuration files, provide Linux-appropriate equivalents or note differences (e.g., discuss app startup/warm-up for Linux containers, not just Web.config).
Avoid Windows-centric terminology or file paths in troubleshooting; provide Linux paths or clarify cross-platform locations.
Ensure parity in feature support explanations: if a feature is not supported on Linux, suggest alternative approaches or workarounds for Linux users.
Present Azure CLI examples before PowerShell, as CLI is cross-platform and more relevant for Linux users.
Where Visual Studio or other Windows-only tools are mentioned, also mention cross-platform deployment tools (e.g., VS Code, GitHub Actions, Azure DevOps pipelines) and how they can be used from Linux.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates some Windows bias, particularly in the following areas: (1) Windows paths and behaviors are often mentioned first or exclusively (e.g., 'D:\home\site\wwwroot' before '/home/site/wwwroot'); (2) The Kudu UI ZIP deploy method is only available for Windows, with Linux users told to use alternative methods; (3) The use of the Azure portal's 'Advanced Tools' (Kudu) is a Windows-centric workflow, and instructions for Linux users are less direct; (4) Some examples and notes (such as startup script deployment) reference Windows-specific paths or behaviors before Linux equivalents; (5) There are no Linux shell or SCP/rsync examples, and no mention of Linux-native tools for file transfer or deployment.

Recommendations:

When mentioning file paths or behaviors, present Linux and Windows variants equally, or mention Linux first where appropriate.
Provide explicit Linux-native examples (e.g., using SCP, rsync, or Linux shell commands) for file deployment scenarios.
Clarify which features are Windows-only and provide clear, step-by-step alternatives for Linux users, not just links.
Where the Azure portal or Kudu UI is referenced, note the parity or lack thereof for Linux, and suggest equivalent Linux-friendly workflows.
Avoid using Windows-centric terminology or tools as the default; instead, use cross-platform tools (like Azure CLI and cURL) as primary examples.
Add a table or section summarizing feature parity and differences between Windows and Linux App Service environments.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ windows_first

Summary:

The documentation page exclusively uses Azure PowerShell commands to demonstrate how to configure Traffic Manager and App Service Environments. There are no examples or references to equivalent steps using Azure CLI, Bash, or other cross-platform tools. The only automation approach shown is PowerShell, which is most commonly associated with Windows environments. This creates a bias toward Windows users and may hinder Linux/macOS users or those who prefer cross-platform tooling.

Recommendations:

Provide equivalent Azure CLI (az) command examples alongside the PowerShell examples for all resource creation and configuration steps.
Explicitly mention that all steps can be performed from Linux/macOS using Azure CLI or the Azure Portal, and provide links or brief instructions.
Include Bash script snippets or references for DNS lookups and other command-line tasks, not just screenshots.
Reorganize sections so that cross-platform tools (Azure CLI, Portal) are mentioned before or alongside PowerShell, rather than PowerShell being the only or primary method.
Add a note clarifying that PowerShell is available on Linux/macOS, but highlight the availability and parity of Azure CLI for users on all platforms.

Create pull request

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 equivalent Linux or cross-platform instructions, and Linux scenarios are not addressed.

Recommendations:

Provide equivalent Linux instructions for uploading and managing certificates, including examples using Bash, OpenSSL, and Linux file paths.
Clarify support for Linux-based App Service apps, including any limitations or alternative approaches.
Include cross-platform or platform-agnostic examples where possible, or clearly label Windows-specific steps.
Offer guidance for checking certificate installation and trust stores on Linux-based App Service workers (e.g., using Bash and OpenSSL commands).
Explicitly state any feature parity gaps between Windows and Linux App Service environments, and link to relevant Linux documentation if available.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a moderate Windows bias, particularly in the .NET and Python sections. Windows tools like Visual Studio and Azure PowerShell are listed before cross-platform or Linux-native tools, and some quickstart links default to Windows or PowerShell tabs. In the Python section, the quickstart links include 'windows' in their tab parameters, suggesting a Windows-first approach. Linux-specific instructions are present but often secondary or less prominent. Other stacks (Java, Node.js, PHP) are more balanced or Linux-focused.

Recommendations:

Ensure that Linux and cross-platform tools (e.g., VS Code, CLI, Azure CLI) are listed before or alongside Windows-specific tools in all tables and quickstarts.
For .NET and Python, provide explicit Linux/WSL and macOS instructions and examples, not just Windows/PowerShell.
Avoid defaulting quickstart links to Windows tabs; use neutral or user-selectable defaults.
Where Azure PowerShell is mentioned, also mention Azure CLI and Bash equivalents, especially for deployment and management tasks.
Audit all quickstart and tutorial links to ensure Linux parity in instructions, screenshots, and code samples.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

Summary:

The documentation provides both Bash and PowerShell examples for all Azure CLI commands, but consistently lists Bash first. There is no exclusive use of Windows tools, but the presence of PowerShell tabs and syntax throughout the article indicates a Windows-centric approach. No Linux-specific tools or patterns are mentioned, but Bash examples are present and complete. There are no missing Linux examples, but the dual tab format may suggest a slight bias towards Windows users by always including PowerShell and referencing 'PowerShell syntax.'

Recommendations:

Consider explicitly stating that Bash examples are suitable for Linux/macOS and that PowerShell is for Windows, to clarify parity.
Add a note confirming that all Azure CLI commands work identically on Linux, macOS, and Windows (with Bash or PowerShell).
If possible, provide a single, unified CLI example when the syntax is identical, reducing the perception of platform bias.
Include troubleshooting or environment preparation notes for both Linux and Windows users, not just generic Azure CLI setup.
Ensure that any references to the Azure portal or tools are not Windows-specific (which is currently the case, but should be monitored in future updates).

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a bias towards Windows by referencing only the Azure Portal (a web GUI) and linking to a PowerShell-based guide for enabling DDoS IP Protection, without providing equivalent CLI (az CLI), Bash, or Linux-native instructions. There are no Linux or cross-platform command-line examples, and the only automation example is PowerShell-focused.

Recommendations:

Add Azure CLI (az) command examples for enabling DDoS Protection on both VNets and public IP addresses, alongside or instead of PowerShell instructions.
Include Bash shell examples for relevant operations, ensuring parity for Linux and macOS users.
When linking to further instructions (such as enabling DDoS IP Protection), provide links to both PowerShell and Azure CLI documentation.
Explicitly mention that all operations can be performed from any OS using Azure CLI, not just via PowerShell or the Azure Portal.
Consider including a table or section comparing methods (Portal, PowerShell, Azure CLI) for each task to highlight cross-platform options.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page references Windows-specific tools (PowerShell) for backend management and omits mention of Linux-native or cross-platform alternatives. No Linux-specific examples or CLI instructions are provided, and PowerShell is the only command-line tool explicitly mentioned.

Recommendations:

Add equivalent Azure CLI examples for backend management tasks, as Azure CLI is cross-platform and widely used on Linux.
Mention that backend entities can also be managed via Azure CLI, and provide a link to relevant documentation.
Ensure that any references to PowerShell are accompanied by Azure CLI or REST API examples to provide parity for Linux and macOS users.
Consider including a note that PowerShell Core is cross-platform, but clarify usage instructions for Linux environments if PowerShell is to be retained.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

Summary:

The documentation provides both Azure CLI and PowerShell examples for managing access restrictions, but PowerShell examples are featured prominently and sometimes appear before CLI examples. There are no explicit Linux shell (bash) or platform-specific examples, but the use of PowerShell commands and terminology may be more familiar to Windows users. The documentation does not mention or provide examples for Linux-native tools or workflows outside of the Azure CLI, which is cross-platform. There is a slight Windows bias due to the prominence and ordering of PowerShell examples.

Recommendations:

Ensure that Azure CLI examples are always presented before or alongside PowerShell examples, as CLI is cross-platform and more familiar to Linux users.
Explicitly mention that both Azure CLI and PowerShell are available in Cloud Shell, which is accessible from any OS.
Where possible, provide bash shell script examples for common tasks, especially for scenarios where scripting is shown (e.g., multi-source rules).
Clarify that all programmatic examples (CLI, ARM, Bicep) are platform-agnostic, and highlight this in introductory sections.
Avoid assuming PowerShell as the default scripting language; balance with bash or sh examples where appropriate.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

Summary:

The documentation provides both Azure CLI and Azure PowerShell examples for configuring Key Vault references, but PowerShell examples are consistently presented immediately after the CLI, and no Linux shell-specific (e.g., Bash) or cross-platform scripting examples are given. The use of PowerShell, which is traditionally associated with Windows, may create a perception of Windows bias, especially as Linux users may expect Bash or shell script examples. However, the CLI examples are cross-platform, which mitigates some of the bias.

Recommendations:

Explicitly note that Azure CLI commands are cross-platform and suitable for Linux, macOS, and Windows.
Where PowerShell is shown, consider also providing Bash or shell script equivalents for Linux users, especially for scripting scenarios involving variables or more complex logic.
In tabbed code blocks, consider listing Bash or Azure CLI first (or clarify that CLI is cross-platform), and PowerShell second, to avoid the impression of Windows-first bias.
Add a brief section or note clarifying that all management operations can be performed from Linux environments using the Azure CLI.
If there are any platform-specific caveats (e.g., for Linux App Service), highlight them clearly and provide Linux-specific troubleshooting steps or examples where relevant.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation page demonstrates a bias toward Windows by omitting any command-line or scripting examples for either Windows or Linux, but when OS is mentioned, Windows is referenced first (e.g., 'Windows to Linux'). There are no examples or guidance for managing App Service plans using Linux-native tools or CLI, nor is there parity in mentioning Linux-specific considerations or workflows.

Recommendations:

Add explicit examples for managing App Service plans using the Azure CLI (az), which is cross-platform and works on both Windows and Linux.
Where OS types are mentioned, alternate the order (e.g., 'Linux or Windows') or clarify that both are supported equally.
Include screenshots or instructions for Linux users, such as using the Azure CLI in a Bash shell or Cloud Shell.
If PowerShell or Windows-specific tools are referenced in other sections, ensure equivalent Linux/Bash examples are provided.
Highlight any differences or considerations specific to Linux App Service plans, if applicable.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation provides a troubleshooting step for clearing the DNS cache that only mentions the Windows-specific command (`ipconfig /flushdns`) and does not provide equivalent instructions for Linux or macOS users. No Linux or cross-platform alternatives are mentioned in this context, which may cause confusion or exclusion for non-Windows users.

Recommendations:

When providing troubleshooting steps that involve OS-specific commands (such as clearing DNS cache), include equivalent commands for Linux (e.g., `sudo systemd-resolve --flush-caches` or `sudo /etc/init.d/nscd restart`) and macOS (e.g., `sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder`).
Wherever possible, use cross-platform language and examples, or explicitly mention steps for all major operating systems.
Review the documentation for other subtle Windows-first assumptions, such as screenshots, terminology, or tool references, and ensure Linux/macOS parity.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation provides a file path example using a Windows path (C:\home\site\wwwroot) first, and only later mentions the Linux equivalent, without providing a Linux-specific example in the main steps. The note about Linux support is secondary and less detailed, and there are no Linux/POSIX shell or tooling examples.

Recommendations:

Provide Linux file path examples alongside or before Windows examples in all instructions.
Explicitly show both Windows and Linux file paths in step-by-step instructions, not just in notes.
Clarify any platform-specific behaviors or limitations in the main instructional flow, not only in notes.
Include Linux/POSIX shell commands or references where relevant, ensuring parity with any Windows-specific instructions.
Consider using platform-agnostic language (e.g., 'the root of your project (deployed to C:\home\site\wwwroot on Windows or /home/site/wwwroot on Linux)') throughout the documentation.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation provides only a C# example using the Microsoft.IdentityModel.Tokens NuGet package for generating the client secret JWT, which is a Windows/.NET-centric approach. There are no examples or references for generating the JWT using common Linux tools (such as OpenSSL, Python, or Node.js), nor are cross-platform command-line instructions provided. The documentation implicitly assumes a Windows/.NET development environment.

Recommendations:

Add examples for generating the client secret JWT using cross-platform tools such as OpenSSL, Python (e.g., PyJWT), or Node.js (e.g., jsonwebtoken).
Include command-line instructions that work on Linux/macOS as well as Windows.
Reference open-source, platform-agnostic libraries for JWT creation and signing.
Explicitly mention that the process can be completed on any OS and provide links or code samples for non-Windows environments.
Consider reordering or supplementing the C#/.NET example with a Linux-first or cross-platform example to ensure parity.

Create pull request

Bias Types:

⚠️ linux_first

⚠️ missing_windows_example

Summary:

The documentation page demonstrates a Linux-first bias in the sections related to Java key store and certificate management. It provides detailed instructions and examples specifically for Linux environments (e.g., file paths, SSH access, keytool usage), while omitting equivalent instructions or examples for Windows-based App Service environments. There are no PowerShell or Windows-specific tools or patterns mentioned, and Windows scenarios are not addressed in parallel with Linux ones.

Recommendations:

Add equivalent instructions for managing Java key stores and certificates on Windows-based App Service, including file paths, environment variables, and any differences in certificate handling.
Provide examples for accessing and managing certificates using Windows tools (such as PowerShell or CMD), and document how to use the Java keytool on Windows App Service environments.
Explicitly state any differences or limitations between Linux and Windows App Service environments regarding Java security configuration.
Ensure that all sections that provide Linux-specific guidance also include Windows-specific guidance where applicable, or clearly indicate if a feature is Linux-only.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation provides detailed, step-by-step SSH access instructions and CLI examples exclusively for Linux containers, while Windows containers are only mentioned briefly and lack equivalent technical guidance. The Windows section states that SSH is supported via the browser but does not explain how to use SSH from the command line or provide any PowerShell or Windows-native SSH client examples. Additionally, the Windows container information is presented before the Linux section, but without technical depth.

Recommendations:

Add equivalent command-line SSH access instructions for Windows containers, including examples using PowerShell and Windows-native SSH clients.
Provide explicit examples for connecting to Windows containers via SSH from both Windows and Linux clients, ensuring parity in technical depth.
Clarify any limitations or differences in SSH support between Linux and Windows containers, and offer workarounds or alternatives where possible.
Consider presenting Linux and Windows instructions in parallel (side-by-side or with clear pivots) to avoid the perception of prioritizing one platform over the other.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation provides command-line examples only for Azure CLI and Azure PowerShell, with no explicit Linux shell or cross-platform command examples (e.g., Bash, curl, sftp, or scp). The only scripting tool mentioned besides the portal is Azure PowerShell, which is primarily a Windows-centric tool, and there are no Linux-native tool examples for interacting with FTP/S or Git endpoints. Additionally, the documentation references escaping the dollar sign in Bash, but does not provide a concrete Bash example.

Recommendations:

Add explicit Bash/shell command examples for common tasks, such as using curl, sftp, or scp for FTP/S deployment, and git commands for local Git deployment.
Include cross-platform notes and examples, especially for credential usage in Linux/macOS environments.
When referencing PowerShell, provide equivalent Bash or Linux-native command alternatives where possible.
Clarify that Azure CLI is cross-platform and can be used on Linux/macOS, and provide sample commands in a Linux shell context.
Add troubleshooting tips or examples for Linux users, such as handling file permissions or credential storage.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page exhibits a subtle Windows bias by referencing UI actions such as 'Right click' and 'click Save' when adding files, which are more familiar to Windows users and Visual Studio users. There are no explicit Linux or cross-platform command-line instructions for these steps, and no mention of Linux-specific tools or editors. Additionally, there are no terminal-based or CLI-based examples for creating files or managing the app, which would help Linux users. The documentation does not provide parity for Linux users in these areas, despite the topic being relevant for cross-platform .NET development.

Recommendations:

Provide equivalent command-line instructions (e.g., using 'touch' and a text editor like 'nano' or 'vim') for creating and editing files, alongside the UI-based instructions.
Avoid UI/IDE-specific language like 'Right click' and 'click Save' as the only method; instead, offer both GUI and CLI alternatives.
Explicitly mention that the steps can be performed on Linux, macOS, and Windows, and provide examples or notes for each where relevant.
Reference cross-platform tools (such as VS Code, dotnet CLI, Azure CLI) and show their usage in addition to or instead of Windows-centric tools.
Where possible, use screenshots or code snippets that are not specific to a single OS, or provide alternatives for each major OS.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

Summary:

The documentation provides both Azure CLI and Azure PowerShell instructions for verifying results, but the PowerShell tab is present and detailed, which can be seen as a Windows-centric approach. The Azure CLI examples are present and listed first, but there is no explicit mention of Linux or macOS environments, nor are there any Bash-specific or cross-platform shell instructions beyond Azure CLI. The PowerShell examples use Windows-style variable assignment and commands, which may not be directly usable on Linux/macOS without PowerShell Core. There are no references to Linux tools or workflows.

Recommendations:

Explicitly mention that Azure CLI commands work on Windows, Linux, and macOS, and provide Bash shell examples where appropriate.
Clarify that PowerShell examples require PowerShell Core for cross-platform compatibility, or provide Bash equivalents.
Add a note or section for Linux/macOS users, highlighting any differences or confirming parity.
Ensure that any variable assignment or scripting examples are shown in both Bash and PowerShell syntax, or use cross-platform syntax where possible.
Consider including a table or tabbed interface for 'Bash', 'PowerShell', and 'Azure CLI' to make parity clear.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation provides deployment examples for multiple platforms. However, the ASP.NET (classic) example is the only one that exclusively uses Windows runners and Windows-specific tools (NuGet, MSBuild), and it appears before the Linux/Ubuntu-based .NET Core example. All other language examples use Ubuntu runners and cross-platform tools. This ordering and tooling choice introduces a subtle Windows bias, especially for .NET developers.

Recommendations:

Provide a Linux/Ubuntu-based example for ASP.NET (classic) if possible, or clarify that Windows is required and explain why.
Reorder the .NET Core and ASP.NET tabs so that the cross-platform .NET Core example appears first, emphasizing modern, cross-platform development.
Where Windows-specific tools are required, explicitly state the reason and, if possible, suggest cross-platform alternatives or workarounds.
Ensure parity in runner environments and tooling across all language examples to avoid implying Windows is the default or preferred environment.

Create pull request

Bias Types:

⚠️ missing_linux_example

Summary:

The documentation page provides instructions and examples that are platform-neutral for most tasks, primarily using the Azure portal and REST APIs. However, the only command-line example given for disabling public network access uses the Azure CLI, which is cross-platform, but there are no explicit Linux shell or Bash examples for DNS validation or network testing. The only DNS validation example uses nslookup, which is available on both Windows and Linux, but no explicit Linux/Bash command (such as dig or host) is shown. There are no PowerShell-specific commands or Windows-only tools mentioned, and the Azure CLI is correctly used as a cross-platform tool.

Recommendations:

When providing DNS validation examples, include both nslookup and dig/host commands to demonstrate parity for Linux users.
Explicitly mention that Azure CLI commands work on Windows, macOS, and Linux, and provide sample shell prompts for Bash/zsh where appropriate.
If referencing command-line utilities, clarify their availability across platforms or suggest installation instructions for Linux if needed.
Consider adding a short section or callout for Linux users, especially in testing and validation steps, to ensure inclusivity.

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation references both Windows and Linux/macOS paths for the hosts file, but lists the Windows path first. There are no command-line examples or tooling references that are Windows-specific, and no examples are missing for Linux. However, the ordering of Windows before Linux in the hosts file path is a subtle form of Windows-first bias.

Recommendations:

List Linux/macOS and Windows hosts file paths in parallel or alternate the order to avoid implying priority.
Where possible, provide explicit command-line examples for both Windows (e.g., PowerShell) and Linux/macOS (e.g., Bash) if relevant operations are discussed.
Review other documentation pages for similar ordering or implicit prioritization and strive for platform neutrality.

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation presents Windows code and container examples before Linux container examples, indicating a 'windows_first' ordering bias. However, Linux content is present and not missing.

Recommendations:

Reorder the pivots so that Linux and Windows examples are presented in parallel or with Linux first, especially since the ms.custom metadata includes 'linux-related-content'.
Explicitly mention that equivalent instructions are available for both Windows and Linux to reassure users of parity.
Consider providing a summary table or section at the top outlining support for both platforms before diving into platform-specific pivots.

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation lists Windows web apps before Linux web apps in the supported workloads and consistently references Windows SKUs and containers first in pricing and feature tables. There are no explicit examples or tooling references, but the ordering and phrasing suggest a subtle Windows-first bias.

Recommendations:

Alternate the order of Windows and Linux mentions throughout the documentation (e.g., 'Linux and Windows web apps').
Where possible, provide equal emphasis on Linux and Windows in feature and pricing tables, or clarify that both are equally supported.
Explicitly mention that all features and capabilities apply equally to Linux and Windows unless there are exceptions, and clearly highlight any such exceptions.
If examples or command-line instructions are added in the future, ensure both Windows (PowerShell/CLI) and Linux (Bash/CLI) examples are provided.

Create pull request

No problematic pages found in this scan. All pages appear to be Linux-friendly! 🐧