Scan Details - Linux-first Docs for Azure

714

Pages Scanned

53

Pages Flagged

714

Changed Pages

7.4%

% Pages Flagged

Live Progress

🔴 Connecting...

0%

Phase: discovery

Processing: Initializing...

Activity Feed

00:01:07 Scan started

Scan Information

Started At: 2025-08-27 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 demonstrates a Windows bias by presenting Azure PowerShell instructions before Azure CLI in tabbed sections, referencing PowerShell-specific cmdlets (e.g., Get-AzProviderFeature) even in CLI sections, and omitting explicit Linux shell or Bash examples. The use of PowerShell is emphasized, and there is no mention of Linux-specific tools, shell environments, or command-line nuances that would assist Linux users.

Recommendations:

Present Azure CLI examples before or alongside PowerShell examples, especially since CLI is cross-platform and more common on Linux.
Ensure that all CLI output and instructions are shown using native az CLI commands, not PowerShell cmdlets, in CLI sections.
Add explicit Bash or Linux shell examples where relevant, such as using az CLI in Bash, and clarify any OS-specific steps or differences.
Mention that Azure CLI works natively on Linux/macOS and provide links or notes for Linux users where appropriate.
Avoid assuming the use of PowerShell as the default scripting environment; clarify that both PowerShell and Bash are supported.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by primarily featuring Azure PowerShell commands and referencing the PowerShell Gallery for migration scripts, with no mention of Bash, Linux, or cross-platform alternatives. The command-line examples use PowerShell cmdlets (Set-AzContext, Get-AzProviderFeature, Register-AzProviderFeature), and the migration tooling is described as a PowerShell script. There are no Bash/Azure CLI (az) examples or explicit Linux instructions, and the PowerShell approach is presented as the default/only method.

Recommendations:

Provide equivalent Azure CLI (az) command examples for all PowerShell commands, especially for registration/unregistration and migration tasks.
Mention that Azure CLI is cross-platform and can be used on Linux, macOS, and Windows.
If migration scripts are only available in PowerShell, offer Bash or Python alternatives, or clarify cross-platform usage (e.g., using PowerShell Core on Linux).
Ensure that documentation and tutorials reference both PowerShell and CLI approaches equally, or at least indicate parity.
Add explicit Linux/macOS instructions or notes where relevant, especially for command-line operations.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation demonstrates a bias toward Windows by providing only PowerShell commands for resource cleanup and configuring backend VMs with IIS (a Windows web server). There are no Linux/CLI/bash examples for resource deletion or for validating the deployment using a Linux-based web server, and the backend pool is implicitly Windows-centric.

Recommendations:

Provide equivalent Azure CLI (bash) commands for resource cleanup, such as 'az group delete'.
Include instructions or a note on how to use a Linux-based web server (e.g., Nginx or Apache) in the backend pool, or link to a Linux VM template.
When referencing PowerShell, always offer a CLI/bash alternative in parallel.
Avoid assuming IIS as the default test workload; offer both Windows (IIS) and Linux (Nginx/Apache) validation steps.
Explicitly mention cross-platform options in all procedural steps, especially for common operations like resource deletion.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation page exhibits a strong Windows bias. All migration tools and examples focus exclusively on migrating from Windows environments, specifically from IIS servers. Only Windows OS and PowerShell scripts are mentioned for migration tasks, with no mention of Linux-based hosting environments, Linux migration tools, or cross-platform alternatives. The App Service Migration Assistant and related scripts are Windows-only, and there are no examples or guidance for migrating .NET apps from Linux servers or using Linux-native tools.

Recommendations:

Include migration guidance and tools for .NET apps hosted on Linux servers (e.g., Apache, Nginx, Kestrel).
Provide Linux shell (bash) script equivalents for PowerShell-based migration steps.
Mention and document any cross-platform or Linux-compatible migration tools, or clarify their absence.
Add examples and scenarios for containerizing .NET apps on Linux and migrating them to Azure App Service (Linux).
Explicitly state platform limitations for each tool and provide alternative recommendations for non-Windows environments.
Ensure parity in documentation structure and examples for both Windows and Linux migration scenarios.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates subtle Windows bias by referencing Windows-specific configuration files (web.config), mentioning iisnode settings for Node.js apps, and omitting Linux-native equivalents or examples. While there is a brief mention of Linux (in the context of using PM2 for Node.js), most configuration and troubleshooting guidance assumes a Windows/IIS environment, and Linux-specific instructions or parity are lacking.

Recommendations:

Provide Linux-native configuration examples alongside Windows ones (e.g., mention app settings or environment variables instead of only web.config).
Include Linux-specific troubleshooting steps and tools (such as using process managers like systemd or supervisord, or Linux-native diagnostic commands).
When referencing iisnode or web.config, also describe how to achieve similar configurations on Linux-based App Service environments.
Ensure that examples and recommendations are balanced between Windows and Linux, or clearly indicate when guidance is platform-specific.
Add explicit Linux examples for auto-healing, scaling, and backup configurations where they differ from Windows.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation demonstrates a mild Windows bias by presenting Windows (and PowerShell) options before Linux equivalents, and by providing a PowerShell automation example but not a Bash/Linux shell script. The Azure portal UI instructions do not distinguish between Windows and Linux, but the scripting section gives more prominence to Windows-centric tools.

Recommendations:

Provide Linux shell (Bash) script examples alongside PowerShell for automation, especially for creating and managing App Service plans.
When listing command-line options (e.g., Azure CLI commands), clarify any differences or requirements for Linux vs. Windows environments.
Present Linux and Windows options in parallel or alternate their order to avoid always listing Windows first.
Explicitly mention that the Azure CLI commands work cross-platform and provide any necessary notes for Linux users.
If referencing portal UI steps, clarify if there are any differences for Linux-based App Service plans or containers.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation demonstrates a moderate Windows bias. Windows SKUs and examples are listed before Linux equivalents, and Azure PowerShell (a Windows-centric tool) is given equal prominence to Azure CLI, despite CLI being more cross-platform. Portal instructions and screenshots are Windows-focused, and there are no explicit Linux shell or scripting examples beyond the CLI. The documentation refers to Windows-specific behaviors and limitations before Linux ones.

Recommendations:

Present Linux and Windows examples in parallel, or alternate which comes first to avoid 'windows_first' bias.
Emphasize Azure CLI as the primary automation tool, as it is cross-platform, and provide Bash shell script examples where appropriate.
Include explicit Linux shell (Bash) automation examples, not just Azure CLI and PowerShell.
Clarify in portal instructions and screenshots when steps or UI differ for Linux-hosted apps.
Where Windows-specific limitations or behaviors are discussed, ensure Linux equivalents are also described if applicable.
Consider a dedicated section for Linux container deployment, since the tier supports custom containers on Linux.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a moderate Windows bias. Windows instructions and tools (such as PowerShell and GUI) are often presented first or exclusively, with Linux alternatives sometimes missing or less detailed. Troubleshooting and testing examples use Windows-specific commands (e.g., PowerShell's Test-NetConnection), and the GUI for Hybrid Connection Manager is only available on Windows. Linux users are directed to CLI usage, but equivalent Linux-native troubleshooting commands are not provided. Some sections, such as troubleshooting, lack parity in Linux examples.

Recommendations:

Provide Linux-native command examples alongside Windows ones (e.g., use 'nc' or 'telnet' for TCP connectivity tests instead of only PowerShell's Test-NetConnection).
Present Windows and Linux instructions in parallel or in a more balanced order, rather than always listing Windows first.
Where a GUI is only available on Windows, offer equivalent CLI workflows for Linux with screenshots and step-by-step instructions.
In troubleshooting sections, include Linux-specific commands for DNS resolution (e.g., 'dig', 'host', or 'nslookup') and network connectivity testing.
Explicitly state any feature gaps or differences between Windows and Linux, and provide workarounds or alternatives where possible.
Ensure that all critical workflows (installation, configuration, troubleshooting) have complete Linux coverage, not just references to CLI.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation demonstrates a Windows bias by providing PowerShell scripts as the only automation example for identifying impacted Traffic Manager endpoints, without offering equivalent Bash or cross-platform (Linux/macOS) alternatives. The guidance for running scripts assumes a Windows/PowerShell environment, and there is no mention of Linux shell, Bash, or cross-platform scripting options. This may hinder Linux/macOS users or those working in non-Windows environments.

Recommendations:

Provide Bash or Azure CLI script equivalents for all PowerShell automation examples, especially for identifying Traffic Manager endpoints.
Explicitly mention that the PowerShell scripts can be run on PowerShell Core (which is cross-platform), or provide instructions for Linux/macOS users.
When referencing scripts, offer both Windows (PowerShell) and Linux/macOS (Bash/CLI) options side by side, or clearly indicate platform compatibility.
Ensure that all automation and scripting guidance is accessible to users regardless of their operating system.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page focuses exclusively on discovering ASP.NET web apps hosted on IIS servers within VMware environments, which are Windows-centric technologies. There are no references to Linux-based hosting environments (such as Kestrel or Apache/Nginx with .NET), nor are there examples or guidance for discovering .NET apps running on Linux servers. All discovery capabilities and examples are implicitly or explicitly tied to 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 discovery of .NET apps on Linux, and if so, provide instructions or links.
Add parity in documentation by listing Linux discovery capabilities alongside Windows/IIS, or clarify if such support is not available.
If only Windows is supported, explicitly state this limitation to set user expectations.
Provide sample discovery flows or troubleshooting steps for both Windows and Linux environments.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ powershell_heavy

Summary:

The documentation is heavily focused on Windows environments, specifically Azure App Service on Windows using iisnode. All configuration examples, troubleshooting steps, and tool references (e.g., iisnode, web.config, named pipes, Win32 error codes, Kudu CMD/PowerShell) are Windows-specific. There are no Linux equivalents or examples provided, and Linux tools or patterns are not mentioned. The document assumes the use of Windows file paths and debugging tools, and does not address how to perform similar tasks on Linux-based App Service environments.

Recommendations:

Add equivalent sections or notes for Linux-based Azure App Service environments, including differences in configuration and troubleshooting.
Provide Linux-specific examples (e.g., using PM2 or systemd instead of iisnode, nginx or Apache configuration, Linux file paths, and log locations).
Include troubleshooting steps and diagnostic commands for Linux (e.g., using SSH, Bash, Linux process monitoring tools like top/htop, journalctl, etc.).
Mention cross-platform Node.js debugging tools and how to use them on both Windows and Linux.
Clearly indicate at the top of the document that the content is Windows-specific, and link to a parallel Linux-focused guide if available.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows-first bias by referencing the Windows file path (C:\home\site\wwwroot) as the default location for the configuration file, and only later mentioning the Linux equivalent. There are no explicit Linux command-line or file path examples, and the instructions and examples default to Windows conventions. The only mention of Linux is in a note, which describes a limitation without providing a Linux-centric example or workflow.

Recommendations:

Provide Linux file path examples alongside Windows examples, or present Linux examples first when discussing cross-platform scenarios.
Include explicit Linux command-line instructions or references (e.g., using bash or Linux file system conventions) where appropriate.
Clarify and expand on Linux-specific behaviors or limitations, ideally with example commands or file paths for both platforms in all relevant sections.
Avoid using Windows paths (e.g., C:\home\site\wwwroot) as the default in instructions; instead, present both Windows and Linux paths together or in parallel.
Where platform differences exist, consider using a table or side-by-side comparison to make parity and differences clear.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation page demonstrates a strong Windows bias. All runtime version examples and tooling references (such as Kudu, CMD, PowerShell, and Visual Studio) are specific to Windows environments. There are no Linux-specific instructions or examples, nor is there mention of Linux-based deployment or configuration patterns for ASP.NET apps. The documentation assumes the use of Windows App Service instances and omits guidance for Linux-based App Service or containers, despite a brief mention in the introductory note.

Recommendations:

Add parallel Linux-based examples for listing .NET runtime versions, such as using SSH or the Linux Kudu Bash console.
Include instructions for configuring and deploying ASP.NET apps on App Service Linux plans, including differences in environment variables, file paths, and diagnostic logging.
Mention and provide examples for Linux-based deployment tools (e.g., dotnet CLI, VS Code, GitHub Actions) alongside Visual Studio.
Clarify when instructions are Windows-specific and provide links or sections for Linux/container-based workflows.
Highlight any differences in accessing diagnostic logs or environment variables between Windows and Linux App Service environments.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation provides both Linux and Windows instructions for configuring data sources in Tomcat and JBoss on Azure App Service. However, in the Tomcat server-level configuration section, the Windows instructions are more detailed and make heavy use of Windows-specific tools and patterns, such as PowerShell scripts and Windows environment variables. The Windows section is longer and more prescriptive, with explicit PowerShell automation, while the Linux section relies on shell scripting and manual steps. The documentation also introduces Windows-specific concepts (e.g., copying Tomcat to a local directory, using %LOCAL_EXPANDED%, and setting up startup.cmd) that have no direct Linux equivalent, and the PowerShell script is given in full, whereas the Linux script is more generic. The Linux instructions are present and functional, but the Windows approach is more prominent and tool-specific.

Recommendations:

Provide equally detailed Linux shell script examples for automating Tomcat server-level configuration, similar to the PowerShell script given for Windows.
Where possible, present Linux and Windows instructions in parallel or with equal prominence, rather than giving a longer, more detailed Windows section.
Include Linux-native automation tools (e.g., bash scripts, systemd service files, or cloud-init) as first-class citizens, not just as generic shell snippets.
Avoid Windows-specific terminology (e.g., %LOCAL_EXPANDED%, startup.cmd) without providing clear Linux equivalents.
Consider providing a table or side-by-side comparison of steps for both platforms to ensure parity and clarity.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page exhibits a Windows-first bias by referencing Windows-style paths (e.g., D:\home\site\wwwroot) before Linux equivalents, and by providing operational details and examples primarily in the context of Windows environments. There is a lack of explicit Linux or cross-platform command examples, and some instructions (e.g., manual directory creation) only mention Windows paths. Linux-specific nuances are only briefly mentioned, and there are no Linux shell or file system examples.

Recommendations:

Provide Linux path examples (e.g., /home/site/wwwroot) alongside Windows paths in all relevant sections, not just in passing.
Include explicit Linux/macOS shell command examples where manual file operations are described (e.g., creating directories, managing files).
Clarify when instructions or behaviors differ between Windows and Linux App Service environments.
Ensure that all file paths, deployment locations, and troubleshooting steps are described for both Windows and Linux environments.
Add a table or section summarizing key differences and commands for both Windows and Linux App Service plans.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a moderate Windows bias, especially in the .NET/ASP.NET section, where Windows tools (Visual Studio, Azure PowerShell) are listed before or alongside cross-platform or Linux-native options. Some quickstart links default to Windows or PowerShell tabs, and the 'Next step' action promotes an ASP.NET (typically Windows-centric) workflow. In Python and some other stacks, Windows is present in tab defaults and URLs, and Linux options are not always presented first or as equally as Windows ones.

Recommendations:

Ensure that Linux and cross-platform CLI examples are presented before or alongside Windows/PowerShell options in all language stacks.
Avoid defaulting to Windows or PowerShell tabs/links in quickstart guides; instead, use neutral or Linux-first defaults where possible.
For .NET/ASP.NET, explicitly provide Linux-based development and deployment workflows (e.g., using .NET CLI on Linux, VS Code on Linux, Azure CLI) and highlight them equally.
In 'Next step' and similar callouts, rotate or randomize the stack/language to avoid always promoting Windows-centric workflows.
Audit all quickstart and tutorial links to ensure Linux and cross-platform instructions are present, up-to-date, and as detailed as Windows equivalents.
Where Windows tools are mentioned (e.g., Visual Studio, PowerShell), always mention Linux alternatives (e.g., VS Code, Azure CLI, Bash) in parallel.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation demonstrates a Windows bias by prioritizing Windows-centric tools and workflows (e.g., Visual Studio, right-click actions, NuGet package manager) and omitting explicit Linux or cross-platform alternatives. There are no Linux-specific instructions or examples, and the use of GUI-based steps (like right-clicking folders) assumes a Windows development environment. Command-line instructions are referenced but not shown, and Linux-friendly editors or deployment methods are not mentioned.

Recommendations:

Provide explicit Linux and cross-platform instructions alongside Windows steps, such as using the dotnet CLI for project/file creation and NuGet package installation.
Include examples for common Linux editors (e.g., VS Code, Vim, nano) and file system navigation.
Replace or supplement GUI-based instructions (e.g., right-click to add files) with command-line equivalents that work on all platforms.
Add deployment guidance for Linux-based development environments, including relevant CLI commands and troubleshooting tips.
Ensure that all referenced tools and workflows (e.g., package management, environment variable configuration) have Linux-compatible alternatives clearly documented.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation page demonstrates a Windows bias by providing only PowerShell examples for command-line operations, referencing Azure PowerShell cmdlets exclusively, and omitting equivalent instructions for Linux users (such as Azure CLI or Bash). The use of PowerShell as the primary automation tool and the absence of cross-platform command-line examples make it less accessible for developers working on Linux or macOS.

Recommendations:

Add Azure CLI examples alongside PowerShell for all command-line operations, as Azure CLI is cross-platform and widely used on Linux and macOS.
Explicitly mention that PowerShell examples are also available on Linux and macOS (if true), or clarify platform requirements.
Provide Bash script examples where appropriate, especially for automation scenarios.
Ensure that documentation sections do not assume Windows as the default environment by presenting cross-platform tools (e.g., Azure CLI) first or in parallel with PowerShell.
Include a note or table summarizing the available tools (PowerShell, Azure CLI, ARM templates) and their platform compatibility.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation provides both Azure CLI and Azure PowerShell examples for finding outbound IP addresses, but PowerShell (a Windows-centric tool) is given equal prominence to CLI, and in some sections, PowerShell is shown immediately after CLI without mention of Bash or Linux-native tools. There are no Linux-specific or Bash-native command examples (e.g., using curl, jq, or REST API with bash), and the only non-Azure CLI command shown is nslookup, which is cross-platform but not explicitly called out as such. Outbound IPv6 support is noted as available only for Windows apps, but this is a platform limitation, not a documentation bias. Overall, the documentation leans toward Windows/PowerShell tooling and does not provide Linux-native or Bash-centric examples, which may disadvantage Linux users.

Recommendations:

Add explicit Bash/Linux-native command examples (e.g., using curl with Azure REST API, jq for parsing JSON, etc.) alongside Azure CLI and PowerShell.
Clearly indicate which commands are cross-platform and which are Windows-specific.
When listing command-line examples, alternate the order or provide tabs for 'Windows (PowerShell)', 'Linux/macOS (Bash/CLI)', and 'Azure CLI' to ensure parity.
Where PowerShell is shown, provide equivalent Bash or shell script snippets for common tasks.
Explicitly mention that Azure CLI is cross-platform and can be used on Linux, macOS, and Windows.
For sections that only show PowerShell, add a note or link to Linux/Bash alternatives.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation exhibits a Windows-first bias by referencing Windows-style paths (e.g., D:\home), using Windows terminology and folder structures throughout, and omitting Linux-specific equivalents or examples. The only tool mentioned for disk usage is a Windows-centric site extension, and there are no Linux command-line or file path examples. While there is a note about Linux containers, the main documentation assumes a Windows environment and does not provide parity for Linux users.

Recommendations:

Provide Linux-specific examples, including file paths (e.g., /home/site) and environment variables as they appear on Linux-based App Service plans.
Mention and demonstrate how to check disk usage and environment variables using Linux tools (e.g., du, df, or bash commands) in addition to the Azure Web Apps Disk Usage extension.
Clarify differences in local cache behavior and configuration between Windows and Linux App Service plans, including any limitations or alternative approaches.
Ensure that all instructions and best practices are applicable to both Windows and Linux environments, or clearly indicate when a feature is Windows-only.
Add a section or callouts for Linux users, summarizing key differences and providing links to relevant Linux documentation.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page exhibits a mild Windows bias. It provides detailed calculations and limits specifically for Windows Containers, while Linux-specific guidance is limited to a brief note about network dependencies for Linux continuous deployment. There are no Linux container-specific examples or parity in subnet/IP calculations. Windows terminology and features (e.g., Windows Server Active Directory, NetBIOS) are mentioned without Linux equivalents or clarifications. The overall structure and examples prioritize Windows scenarios, with Linux-specific information appearing only as exceptions or footnotes.

Recommendations:

Add a parallel section for Linux Containers, including subnet/IP address calculation examples and any unique limitations or considerations.
Where Windows-specific features or limitations are mentioned (e.g., Windows Server Active Directory, NetBIOS), clarify Linux equivalents or explicitly state if not applicable.
Provide Linux-focused deployment and configuration examples, especially for common scenarios such as scaling, networking, and troubleshooting.
Ensure that Linux and Windows guidance are presented with equal prominence and detail, ideally side-by-side or in clearly labeled subsections.
Expand the Linux continuous deployment section to include more comprehensive guidance, such as required endpoints, troubleshooting tips, and best practices.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation exhibits a Windows-first bias: logging types and features are described for Windows in greater detail and are presented before Linux equivalents. Several logging features (web server logging, detailed error messages, failed request tracing) are described only for Windows, with no Linux instructions or explicit mention of Linux support or alternatives. Tooling references (e.g., Log Parser, W3C log format) are Windows-centric. Linux logging capabilities are described in less detail, and some features are noted as unavailable or limited for non-Windows stacks.

Recommendations:

Provide equivalent Linux/container instructions for all logging types, or explicitly state when features are unavailable on Linux.
Add Linux-specific examples and clarify differences in log formats, locations, and access methods.
Mention and recommend cross-platform or Linux-native tools for log analysis (e.g., grep, less, jq) alongside or instead of Windows tools like Log Parser.
Ensure parity in detail and structure between Windows and Linux sections, including tables and step-by-step guides.
Clearly indicate feature availability per platform in all relevant sections, not just in summary tables.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page exhibits a Windows-centric bias in several areas. Diagnostic and troubleshooting tools such as Kudu and Procdump are described with a focus on Windows environments, and PowerShell/DOS commands are mentioned as the default for the debug console. Application Insights Profiler is linked specifically to Windows instructions. There are no explicit Linux or cross-platform examples, and Linux-native tools or workflows are not discussed. Azure PowerShell is recommended for app management without mention of Azure CLI or Linux shell equivalents.

Recommendations:

Add equivalent Linux examples and instructions throughout, especially for diagnostic and troubleshooting steps.
Mention and provide examples for using Azure CLI and Bash shell alongside or instead of Azure PowerShell.
Clarify which features/tools are available on both Windows and Linux App Service plans, and note any differences.
Include Linux-native tools (e.g., strace, lsof, top) for troubleshooting and explain how to access them in App Service for Linux.
Update links and references to include both Windows and Linux documentation where available.
In sections mentioning Kudu, clarify the differences in available commands and features between Windows and Linux App Service environments.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation shows a moderate Windows bias. Visual Studio Code (a Microsoft product popular on Windows) is the only IDE mentioned for test running, and all screenshots and portal instructions are Windows-centric. There are no explicit Linux/macOS-specific instructions, CLI examples, or screenshots. The use of PowerShell for .NET package installation and the absence of Linux/macOS equivalents (e.g., bash or zsh) further reinforce the bias. The documentation assumes familiarity with Windows tools and patterns, and does not provide parity for Linux users in environment setup, CLI usage, or troubleshooting.

Recommendations:

Provide explicit Linux/macOS CLI examples alongside Windows/PowerShell commands (e.g., use both 'dotnet add package ...' and 'dotnet add package ...' in bash/zsh).
Include screenshots or instructions that are platform-agnostic or show both Windows and Linux environments where possible.
Mention and demonstrate how to run Playwright tests from common Linux shells (bash, zsh) and editors (such as VS Code on Linux, or alternatives like Vim/Emacs).
Clarify that the Azure CLI and Playwright tools are cross-platform, and provide any Linux/macOS-specific installation or troubleshooting tips.
Avoid assuming Visual Studio Code is the only or default editor; mention that any editor or terminal can be used.
Add a note or section for Linux/macOS users on environment variable setup, file paths, and permissions if relevant.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows-first bias in both structure and content. Windows instructions, tools, and examples (especially PowerShell) are consistently presented before Linux equivalents, and in greater detail. PowerShell is the default scripting language for runbook examples, with no Linux shell or Python examples provided. Windows-specific tools and paths are referenced more frequently and with more depth than their Linux counterparts. Some advanced features, such as Hybrid Worker Credentials, are not supported on Linux, but this is only noted in passing. There is a lack of parity in example scripts and troubleshooting guidance for Linux users.

Recommendations:

Present Windows and Linux instructions in parallel or use tabs to allow users to select their OS, rather than listing Windows first.
Provide equivalent Linux shell (bash) or Python examples alongside PowerShell examples, especially for common runbook tasks.
Include Linux-specific troubleshooting steps and example scripts where Windows examples are given.
Ensure that references to tools, paths, and environment variables are balanced between Windows and Linux, and avoid assuming PowerShell as the default.
Clearly indicate feature gaps for Linux and, where possible, provide workarounds or alternative guidance.
Expand documentation for Linux-specific configuration, such as credential management and logging, to match the depth provided for Windows.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ powershell_heavy

Summary:

The documentation demonstrates a Windows bias in several ways. Windows-specific concepts (such as registry keys and Windows services) are described in detail, with entire sections and tables dedicated to Windows registry monitoring and example queries referencing Windows file paths and services before Linux equivalents. While Linux is mentioned and some parity is attempted (e.g., Linux daemons, Linux packages), Linux-specific examples are sparse or missing, especially for advanced scenarios (e.g., no Linux equivalent to the detailed registry key monitoring section, and alerting examples are Windows-heavy). Command-line examples use PowerShell-style syntax and focus on Windows first. Windows tools and patterns (like registry, services, .exe files) are discussed more thoroughly than their Linux counterparts.

Recommendations:

Add equivalent Linux-focused sections, such as monitoring important Linux configuration files (e.g., /etc/passwd, /etc/ssh/sshd_config), and provide example queries for these.
Include a table or section listing important Linux daemons and configuration files that are commonly tracked, similar to the Windows registry key table.
Balance example queries so that Linux scenarios (e.g., tracking changes to /etc/hosts or systemd services) are presented alongside or before Windows examples.
Provide more Linux-specific troubleshooting tips, limitations, and best practices, not just Windows-centric notes.
Ensure that command-line examples are provided in both PowerShell and Bash (or at least clarify that az CLI commands are cross-platform and show Linux shell usage where appropriate).
Review the order of presentation so that Linux and Windows are treated equally throughout, rather than Windows-first.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation provides environment variable setup instructions for Windows (cmd and PowerShell) before Linux/macOS, and includes explicit commands for Windows tools (setx, PowerShell) alongside bash. This ordering and explicit mention of Windows tools, with Linux/macOS instructions always last, demonstrates a Windows-first and Windows-tools bias. However, Linux/macOS instructions are present and complete, and there are no missing Linux examples for the Go code itself.

Recommendations:

Present environment variable setup instructions for all platforms in parallel (e.g., in a table or side-by-side tabs), or rotate which OS appears first to avoid always privileging Windows.
Avoid giving Windows instructions (cmd, PowerShell) first by default; consider starting with bash (Linux/macOS), or presenting all equally.
Where possible, use cross-platform commands or note platform-specific differences only when necessary.
Explicitly state that all platforms are supported and tested, and provide troubleshooting tips for both Windows and Linux/macOS environments.
If using tabs, ensure the default selected tab is not always Windows.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation demonstrates a moderate Windows bias. Windows-specific tools and configuration steps (such as Visual Studio, PowerShell, and Windows runtime identifiers) are often mentioned first or in more detail than their Linux equivalents. Some CLI examples and deployment instructions are Windows-centric, and Linux alternatives are sometimes only briefly referenced or relegated to tabs. There are also places where Linux-specific examples or troubleshooting steps are missing or less emphasized, especially around deployment, debugging, and performance optimization.

Recommendations:

Ensure that all CLI and deployment examples are provided for both Windows and Linux, with equal detail and prominence.
When listing tools or configuration steps, present cross-platform options (e.g., Azure CLI, Visual Studio Code) before or alongside Windows-only tools (e.g., Visual Studio, PowerShell).
Include Linux-specific troubleshooting and debugging instructions, especially for scenarios like remote debugging and ReadyToRun publishing.
Where platform-specific tabs are used, ensure both Windows and Linux tabs are present and equally detailed.
Explicitly mention any differences in behavior or requirements between Windows and Linux throughout the document, not just in isolated sections.
Provide parity in example commands (e.g., az CLI, dotnet publish) and clarify any OS-specific flags or considerations.
Review all references to project file settings (like RuntimeIdentifier) and ensure Linux values are always included alongside Windows values.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation generally aims for cross-platform parity but exhibits subtle Windows bias. Command-line examples are consistently provided for both Bash (Linux/macOS) and Cmd (Windows), but the Windows/Cmd examples are always presented after Bash, which is a positive sign. However, there is a lack of explicit PowerShell examples, but the use of 'command prompt' and 'Cmd' tabs may implicitly favor Windows users. Some references, such as 'command prompt' and 'open a new command prompt, Bash, or Terminal session,' prioritize Windows terminology or list it first. There are no Linux-specific tools or troubleshooting sections, and some instructions (e.g., setting JAVA_HOME) do not clarify platform-specific differences. IDE guidance includes both Windows- and Linux-friendly tools, but there is a slight tendency to mention Windows-first patterns.

Recommendations:

Add explicit PowerShell examples or clarify that Bash examples are for Linux/macOS and Cmd for Windows, and consider including PowerShell where relevant.
When referencing terminals, use neutral phrasing such as 'terminal or command prompt' and avoid listing 'command prompt' first.
Include Linux-specific troubleshooting tips, such as setting JAVA_HOME on Linux, file permissions, or common issues with Maven on Linux.
Ensure that all environment variable and path examples are shown for both Windows and Linux (e.g., JAVA_HOME path formats).
Where possible, provide parity in tool recommendations, such as mentioning Linux package managers for JDK installation.
Review the order of presentation in tables and lists to ensure Linux is not always listed after Windows.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation is generally cross-platform and Linux-focused for hosting, but there are subtle Windows biases. Windows terminology ('command prompt'), Windows-first phrasing, and recommendations for remote build when 'developing Python apps on Windows' are present. Visual Studio Code is emphasized, but that's cross-platform. There is a lack of explicit Linux shell (bash) examples, and some folder structure examples use Windows-style command prompt blocks. The documentation does not provide PowerShell-specific commands, but it does use 'command prompt' and 'cmd' block types, which are Windows-centric. However, Linux is clearly the primary supported platform for hosting, and this is stated.

Recommendations:

Replace 'command prompt' and 'cmd' code block types with 'terminal' or 'shell', and use bash syntax for examples where appropriate.
When listing development options, mention Linux/macOS terminals explicitly alongside Windows command prompt.
Provide explicit bash/zsh shell command examples in addition to or instead of Windows command prompt/cmd examples.
Avoid Windows-first phrasing such as 'Use remote build when you're developing Python apps on Windows'; instead, clarify platform-agnostic recommendations.
Where folder structures are shown, use neutral formatting or provide both Windows and Linux/macOS examples if paths or commands differ.
Consider adding a section or callout for Linux/macOS users if there are any platform-specific steps or tips.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation provides both Linux and Windows instructions for most steps, but there is a slight Windows bias in the ordering and presentation. Windows examples and tools (such as PowerShell and Windows-specific storage/file share instructions) are sometimes presented before or more prominently than their Linux equivalents. Some CLI scripts assume a Windows shell environment, and there is heavier use of Windows terminology and tools (e.g., references to Azure Files, Windows environment variables, and PowerShell-style scripting). However, Linux parity is generally good, with dedicated Linux tabs and instructions throughout.

Recommendations:

Ensure Linux and Windows instructions are always presented in parallel, with neither consistently preceding the other.
Where possible, provide Bash and PowerShell script examples side-by-side, or clarify which shell is assumed.
Avoid Windows-centric terminology when describing cross-platform features (e.g., refer to 'file shares' generically, not just 'Azure Files').
Explicitly mention required tools for both platforms (e.g., jq for Linux, PowerShell equivalents for Windows).
Audit all CLI scripts for shell compatibility and provide both Bash and PowerShell variants where needed.
Review and balance the use of screenshots or UI references from both Windows and Linux environments.
Highlight any platform-specific limitations or differences up front, so users can quickly identify relevant sections.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation demonstrates a moderate Windows bias, primarily through the prominence and prioritization of PowerShell examples and references to Windows-centric tools and workflows. PowerShell is highlighted in notes and examples, sometimes before or alongside Azure CLI, and there is an assumption of Visual Studio usage for configuration. There is little to no explicit mention of Linux shell or cross-platform scripting alternatives, and some links and guidance (such as for Redis or Application Insights) direct users to PowerShell-based instructions.

Recommendations:

Ensure that all command-line examples are provided in both PowerShell and Bash/Azure CLI formats, with equal prominence and clarity.
When referencing tools like Visual Studio, also mention cross-platform alternatives (e.g., VS Code, JetBrains Rider) and provide equivalent configuration steps for Linux/macOS users.
Avoid language that assumes a Windows environment by default; clarify when instructions are platform-agnostic or provide OS-specific guidance as needed.
Where links point to PowerShell-heavy documentation (e.g., Redis management), add or reference equivalent CLI or REST API documentation.
In developer guidance, explicitly state that all major Azure SDKs and tools are cross-platform, and provide links to Linux/macOS installation and usage guides.
Review and update any tables or sections that reference Windows-specific endpoints, tools, or workflows to ensure Linux parity is maintained.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows bias by exclusively providing instructions and examples for managing SMB permissions and shares using Windows tools (e.g., MMC, Windows SMB client). There are no Linux-based examples or guidance for accessing or managing SMB volumes from Linux clients, despite SMB being a cross-platform protocol. Windows terminology and workflows are prioritized, and Linux alternatives are not mentioned.

Recommendations:

Include examples for accessing and mounting SMB volumes from Linux clients (e.g., using the 'mount -t cifs' command).
Provide instructions for managing SMB permissions from Linux, such as using 'smbclient', 'smbcacls', or 'setfacl' where appropriate.
Mention and demonstrate how to view or modify SMB share properties from Linux or cross-platform tools, not just Windows MMC.
Balance screenshots and walkthroughs to show both Windows and Linux client perspectives.
Clarify that SMB volumes can be accessed from non-Windows systems and link to relevant Linux documentation.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias in the command-line examples for feature registration, as all code snippets use Azure PowerShell cmdlets (Register-AzProviderFeature, Get-AzProviderFeature) and are formatted as PowerShell. While Azure CLI is mentioned as an alternative, no CLI examples are provided inline, and no Linux/macOS-specific guidance or screenshots are present. The UI instructions also use Windows-centric terminology (e.g., 'right-click'), and there are no explicit Linux or cross-platform instructions or visuals.

Recommendations:

Provide equivalent Azure CLI examples (e.g., 'az feature register', 'az feature show') alongside PowerShell for all feature registration and status-checking steps, with full command syntax and expected output.
Include notes or sections clarifying that all CLI commands can be run on Linux, macOS, and Windows, and provide platform-agnostic instructions.
Where UI instructions mention 'right-click', clarify how to perform the same action on macOS/Linux (e.g., 'right-click or use the context menu').
Add screenshots or notes that reflect the experience on non-Windows platforms, or state that the UI is consistent across platforms if applicable.
Consider a 'Platform requirements' or 'Cross-platform usage' section to explicitly address Linux/macOS users and ensure parity.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation demonstrates a Windows bias by providing detailed, step-by-step instructions for setting SACLs (auditing) on SMB shares using the Windows GUI, while the equivalent Linux/NFS instructions are minimal and refer users to a separate page for details. The document also repeatedly refers to performing actions from a 'Windows administration host' and does not provide Linux command-line examples or GUI walkthroughs for NFS/UNIX environments. Windows tools and workflows are mentioned first and in more detail, while Linux guidance is less direct and less actionable.

Recommendations:

Provide explicit, step-by-step instructions for setting Audit ACEs on NFSv4.1 volumes from a Linux client, including example commands (e.g., using nfs4_setfacl or setfacl).
Include Linux command-line examples for relevant tasks, such as configuring ACLs, in parity with the detailed Windows GUI steps.
Balance the order of presentation so that Linux/NFS instructions are given equal prominence and detail as Windows/SMB instructions.
Where possible, avoid referring users to external pages for Linux/NFS instructions if Windows instructions are included inline.
If GUI-based instructions are provided for Windows, consider providing equivalent instructions for popular Linux desktop environments or clarify that only command-line methods are available.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by listing PowerShell as a primary tool for snapshot management, mentioning it before Linux/Unix equivalents, and omitting explicit Linux/Unix shell or scripting examples. While Azure CLI and REST API are mentioned (which are cross-platform), the only command-line example linked is for PowerShell, and there are no bash or Linux-native workflow examples. This may make Linux users feel less directly supported or require them to infer Linux usage from Windows-centric instructions.

Recommendations:

Add explicit Linux/bash command-line examples for snapshot management alongside PowerShell, especially in sections listing management methods.
When listing tools (Azure portal, REST API, CLI, PowerShell), alternate the order or explicitly note cross-platform parity (e.g., 'Azure CLI (Windows, Linux, macOS)').
Provide sample scripts or links for Linux environments (e.g., bash scripts using Azure CLI) similar to the PowerShell examples.
Reference Linux-native automation and scripting patterns (e.g., cron jobs with Azure CLI) where automation is discussed.
Ensure that any references to scripting or automation do not assume a Windows environment by default.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias by prioritizing Windows/SMB and Active Directory scenarios, referencing Windows-specific tools and features (such as Group Policy, registry settings, and Windows server-side configuration), and providing detailed explanations for Windows security mechanisms (e.g., UNC hardening, LDAP signing) without equivalent Linux or open-source examples. There is a lack of Linux/NFS client configuration guidance, and Linux tools or patterns are not mentioned or are only referenced after Windows equivalents.

Recommendations:

Provide parallel Linux/NFS client configuration examples for encryption, such as how to enable and verify NFS Kerberos encryption on common Linux distributions.
Include references to Linux tools (e.g., sssd, nfs-utils, kinit, ldap-utils) and how they interact with Azure NetApp Files for encryption and authentication.
Balance the order of presentation so that Linux/NFS and Windows/SMB scenarios are given equal prominence, or alternate which is presented first.
Offer guidance on configuring LDAP signing and StartTLS from Linux/Unix clients and servers, not just Windows Active Directory.
Add troubleshooting tips and best practices for Linux environments, including packet capture examples using Linux tools (e.g., tcpdump, Wireshark on Linux).
Reference open-source documentation and standards (e.g., MIT Kerberos, OpenLDAP) alongside Microsoft documentation.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a subtle Windows bias by providing a 'Next steps' deployment link that defaults to a Windows-specific installation tab (install-helm-windows), without mentioning or linking to Linux/macOS equivalents. There are no explicit PowerShell or Windows command examples in the main content, but the navigation flow prioritizes Windows users and omits Linux-first guidance.

Recommendations:

Ensure that all deployment and installation guides linked from this page offer clear parity between Windows and Linux/macOS instructions, ideally defaulting to a neutral or most common platform (such as Linux) or providing platform selection tabs up front.
Explicitly mention that instructions are available for both Windows and Linux/macOS, and provide direct links or navigation cues for each.
Review all linked quickstarts and ensure that Linux/macOS installation steps are as prominent and complete as Windows steps.
Consider adding a short section or note in this page clarifying that Application Gateway for Containers is platform-agnostic and that all major OSes are supported for management and deployment tasks.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page focuses exclusively on assessing ASP.NET web apps, implicitly targeting Windows environments. There are no examples, tools, or instructions provided for assessing .NET web apps running on Linux. All referenced resources and terminology (such as ASP.NET) are traditionally associated with Windows, and there is no mention of Linux-based .NET Core or cross-platform scenarios.

Recommendations:

Include explicit guidance and examples for assessing .NET web apps running on Linux, such as .NET Core or ASP.NET Core apps.
Reference tools and workflows that are cross-platform or provide Linux-specific alternatives where applicable.
Clarify in the introduction whether the assessment process applies to both Windows and Linux-hosted .NET web apps, and update terminology to reflect cross-platform support.
Add links to documentation or tutorials for assessing Linux-based .NET web apps, if available.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias by exclusively referencing the Azure portal UI and not providing any command-line examples (such as Azure CLI, PowerShell, or Bash). There are no platform-specific instructions, but the absence of Linux-oriented or cross-platform command-line examples means Linux users are underserved. All steps are described in terms of portal navigation, which is platform-agnostic but implicitly assumes a GUI workflow common to Windows environments. No Linux tools, shell commands, or deployment patterns are mentioned.

Recommendations:

Add Azure CLI examples for all major configuration steps (e.g., app registration, authentication provider setup, managed identity assignment), as the CLI is cross-platform and widely used on Linux.
Where PowerShell is relevant, provide Bash or shell script equivalents.
Include explicit notes or sections for Linux/macOS users, especially for tasks like managing secrets, environment variables, or automating setup.
Reference cross-platform tools (e.g., az CLI) before or alongside any GUI-based instructions.
If portal navigation is the only method, clarify that the steps are platform-agnostic and provide links to CLI or REST API documentation for automation and scripting use cases.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page focuses exclusively on configuring GitHub authentication via the Azure Portal GUI, which is a web-based interface and not inherently OS-specific. However, it omits any command-line examples or automation steps, such as using Azure CLI, PowerShell, or Bash scripts. There is no mention of Linux tools or workflows, nor are there any CLI-based instructions that would be relevant for Linux users. The absence of Linux-specific or cross-platform command-line examples results in an implicit bias, as many Azure docs often provide PowerShell or Windows-first CLI examples.

Recommendations:

Add Azure CLI examples for configuring GitHub authentication, as the CLI is cross-platform and widely used on Linux.
Include Bash script snippets where appropriate, especially for automation scenarios.
If PowerShell examples are added, ensure equivalent Bash/Azure CLI examples are provided and presented with equal prominence.
Explicitly mention that all steps can be performed from any OS via the Azure Portal, and provide links to CLI documentation for users who prefer command-line workflows.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation shows mild Windows bias by referencing Azure Storage Explorer with a direct link to the Windows tab for generating SAS tokens, and by mentioning Storage Explorer as the primary tool for file uploads and SAS generation. There are no explicit Linux or cross-platform alternatives suggested for these steps, and the only tool-specific instructions are Windows-centric.

Recommendations:

Include explicit instructions or links for using Azure Storage Explorer on Linux and macOS, or clarify that the tool is cross-platform.
Provide alternative command-line examples (e.g., using Azure CLI or AzCopy) for uploading files and generating SAS tokens, which work on all platforms.
Avoid linking directly to the Windows-specific tab in documentation; instead, link to a neutral or cross-platform section.
Mention that all Azure CLI commands shown are cross-platform, and highlight any platform-specific considerations if they exist.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page presents Windows container SSH access information before Linux, but only provides detailed, step-by-step SSH instructions and CLI examples for Linux containers. There are no equivalent command-line or tooling examples for Windows containers, and the documentation notes that SSH via Azure CLI is not supported for Windows containers, with no alternative methods or troubleshooting guidance provided.

Recommendations:

Provide parity in example depth: If Windows containers do not support Azure CLI SSH access, explicitly state this and suggest any available alternatives (such as RDP, PowerShell Remoting, or other remote management tools) or clarify the roadmap for feature parity.
Include troubleshooting and configuration details for Windows containers similar to the Linux section, or clearly state the limitations and expected user experience.
If browser-based SSH is the only supported method for Windows containers, provide a detailed walkthrough and screenshots, matching the depth of the Linux CLI section.
Consider reordering or balancing the presentation so that Linux and Windows instructions are equally prominent, or use side-by-side tabbed content to avoid the perception of a 'windows_first' bias.
If possible, provide links to additional resources for Windows container management to help users achieve similar administrative goals as those shown for Linux.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation references a Python quickstart link that includes 'windows' as a tab and does not provide explicit Linux or cross-platform command-line examples for key setup and deployment steps. There are no explicit Linux shell or bash commands shown for environment variable setup or deployment, and the only mention of command-line usage is via pip (which is cross-platform). The documentation assumes use of the Azure Portal or Visual Studio for deployment and environment variable management, which are more commonly associated with Windows workflows. There is no mention of Linux-specific tools or deployment patterns.

Recommendations:

Provide explicit Linux/bash command-line examples for setting environment variables, running the app, and deploying to Azure App Service.
Ensure that quickstart and sample links default to or include Linux/bash tabs, not just Windows.
Include instructions for using cross-platform tools (such as Azure CLI in bash) for all setup and deployment steps.
Mention and demonstrate Linux-friendly editors (such as VS Code in WSL or on Linux) and deployment workflows.
Clarify that all steps can be performed on Linux, macOS, or Windows, and provide parity in instructions and screenshots where relevant.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation assumes the use of GitHub Codespaces (which is Linux-based), but all terminal instructions are generic and do not mention Windows-specific tools or PowerShell. However, there is an implicit Windows/.NET bias in that the entire tutorial is centered around ASP.NET Core, NuGet, and .NET CLI, with no mention of Linux-specific workflows, alternative editors, or deployment methods outside of Azure App Service. There are no explicit Linux command-line examples, nor are there any references to Linux package managers or shell environments. The documentation also assumes the use of Azure Developer CLI (azd) and dotnet CLI, which are cross-platform, but does not provide parity examples for Linux users or mention any Linux-specific considerations.

Recommendations:

Explicitly mention that all CLI commands work on both Windows and Linux, and provide any necessary shell-specific notes (e.g., path separators, environment variable syntax).
Include a note or section for Linux users, highlighting any differences in setup, deployment, or troubleshooting.
Provide alternative instructions for running the sample app locally on Linux (e.g., using Bash, systemd, or Docker), not just in Codespaces or Azure.
If referencing editors or tools, mention cross-platform options (e.g., Visual Studio Code, JetBrains Rider) and not just Visual Studio (Windows).
Clarify that Azure App Service supports both Windows and Linux hosting, and provide links to documentation for both.
Add troubleshooting tips for common Linux-specific issues (e.g., file permissions, case sensitivity, dependency installation).

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a subtle Windows bias by referencing Visual Studio Credential as the first and only concrete example of a development environment, which is primarily a Windows tool. There are no explicit examples or instructions for Linux or cross-platform environments, nor are command-line examples (such as Azure CLI or Bash) provided. The documentation assumes portal-based or Visual Studio-based workflows, which may not be as accessible or common for Linux users.

Recommendations:

Include explicit examples for Linux and cross-platform environments, such as using Azure CLI or Bash scripts to assign roles or authenticate.
Mention and provide examples for development environments commonly used on Linux, such as VS Code, JetBrains Rider, or command-line workflows.
When discussing DefaultAzureCredential, clarify how it works in non-Windows environments and provide guidance for Linux/macOS users.
Balance references to Visual Studio with equivalent cross-platform tools or IDEs.
Provide step-by-step instructions for role assignment using Azure CLI or PowerShell Core (which is cross-platform), not just the Azure Portal.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation demonstrates mild Windows bias by prioritizing Windows-specific patterns and tools. Windows is mentioned first in several contexts (e.g., use of WSL, Windows Terminal), and PowerShell is referenced alongside Azure CLI for key retrieval. However, Linux installation and usage are well covered, and redis-cli commands are platform-agnostic.

Recommendations:

Provide explicit Linux and macOS instructions for retrieving cache keys (e.g., using Azure CLI), not just Azure PowerShell and portal.
Avoid framing Windows as the default or primary platform (e.g., do not suggest WSL as the 'best way' for Windows users without also mentioning native Linux/macOS usage).
When referencing tools like Windows Terminal, also mention common Linux/macOS terminal applications.
Ensure all examples and instructions are presented in a platform-neutral order, or alternate which OS is mentioned first.
Add a section or note clarifying that redis-cli usage is identical across platforms once installed.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation demonstrates a subtle Windows bias by referencing Windows-centric tools and workflows (such as Visual Studio Code and Azurite) without explicitly addressing Linux alternatives or usage differences. The instructions for starting Azurite and running the function app use command palette steps that are most familiar to Windows users, and there is no mention of Linux-specific considerations or terminal commands. Additionally, the documentation assumes the use of Visual Studio Code, which, while cross-platform, is more commonly associated with Windows development environments.

Recommendations:

Explicitly mention that Visual Studio Code and Azurite are cross-platform, and provide links or notes for Linux installation and usage.
Include terminal command alternatives for starting Azurite and running/debugging the function app (e.g., `azurite` and `func start`), especially for Linux users who may prefer CLI workflows.
Add a brief section or callout for Linux/macOS users highlighting any differences in setup, permissions, or file paths.
Ensure that all steps referencing the command palette or keyboard shortcuts clarify any OS-specific differences (e.g., <kbd>Ctrl</kbd> vs <kbd>Cmd</kbd> on macOS).
Where possible, provide bash/zsh shell commands alongside GUI instructions, especially for steps like updating configuration files or starting services.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation exhibits a mild Windows bias by referencing Windows-specific documentation and tools before or instead of Linux equivalents. For example, the link to 'Create a PPG using the Azure portal' points to a Windows-specific path (/azure/virtual-machines/windows/proximity-placement-groups-portal), and there is no mention of Linux-specific guidance or examples. There are no PowerShell-heavy examples or command-line snippets, but the documentation assumes a Windows-centric workflow in its references.

Recommendations:

Provide equivalent Linux documentation links alongside or before Windows links (e.g., link to /azure/virtual-machines/linux/proximity-placement-groups-portal).
Include Linux-specific considerations or examples where relevant, especially for SAP HANA deployments which are often on Linux.
Review all referenced documentation to ensure parity between Windows and Linux guidance.
Avoid using Windows-specific terminology or paths as the default; use OS-neutral or dual-path references where possible.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation page provides a comprehensive list of solution architectures for Azure NetApp Files, organized by workload type. While both Linux and Windows solutions are covered, there is evidence of Windows bias in the ordering and emphasis: the introduction often lists 'Windows Apps and SQL Server' before Linux equivalents, and Windows-specific tools (such as DFS Namespaces, FSLogix, and SMB) are highlighted in several solution areas. Some sections (e.g., Virtual Desktop Infrastructure) focus almost exclusively on Windows technologies, with little mention of Linux alternatives. However, Linux workloads are well-represented in their own dedicated sections, and many SAP and HPC solutions are Linux-centric.

Recommendations:

Ensure parity in example depth and tool coverage for Linux and Windows across all sections. For example, where Windows DFS or FSLogix are mentioned, include equivalent Linux/NFS or open-source solutions if available.
Review section ordering and introductory text to avoid always listing Windows first; alternate or group by workload type rather than OS.
In sections like Virtual Desktop Infrastructure, explicitly mention Linux-based VDI solutions (if supported) or clarify Windows-only support.
Where Windows-specific tools (e.g., SMB, DFS, FSLogix) are discussed, provide Linux/NFS alternatives or cross-reference to Linux-focused documentation.
Highlight cross-platform best practices and tools that work for both Linux and Windows workloads, to reinforce Azure NetApp Files' versatility.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

Summary:

The documentation page demonstrates a mild Windows bias by providing an Azure PowerShell example first and in more detail for feature registration, with the Azure CLI (cross-platform) alternative only mentioned secondarily and without a full example. There are no explicit Linux-specific examples or instructions, and the documentation does not provide parity in command-line guidance for Linux users.

Recommendations:

Provide full Azure CLI command examples alongside PowerShell, not just references or links.
Present Azure CLI (cross-platform) and PowerShell examples together, or list CLI first to avoid Windows-first ordering.
Where relevant, include Linux-specific considerations or examples, especially in sections referencing performance benchmarks or management tasks.
Clarify that both Azure CLI and PowerShell are supported on multiple platforms, and provide guidance for both environments.
If mentioning tools or commands, ensure parity by offering both Windows and Linux equivalents, or explicitly state when a step is platform-agnostic.

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation page lists .NET and ASP.NET Core provider libraries first in the table, followed by Java, Python, JavaScript, and Go. This ordering implicitly prioritizes Windows-centric technologies, as .NET and ASP.NET Core are traditionally associated with Windows environments, even though they are now cross-platform. There are no explicit Windows-only tools or PowerShell examples, and Linux is not mentioned at all, but the ordering and focus suggest a subtle Windows-first bias.

Recommendations:

Reorder the provider libraries table to group by language family or present all platforms equally, possibly rotating the order or using alphabetical order.
Explicitly mention cross-platform compatibility for .NET and ASP.NET Core providers, highlighting Linux and macOS support.
Add a note or section clarifying that all listed providers are supported on both Windows and Linux (where applicable), and provide links or references to Linux-specific usage or deployment guides if available.
Ensure that future documentation and samples include Linux command-line and deployment examples alongside any Windows-specific instructions.

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation mentions PowerShell before Azure CLI when listing tools for creating resource groups, which may suggest a Windows-first perspective. However, both PowerShell and Azure CLI are referenced, and no examples or instructions are given that are exclusive to Windows or PowerShell. There are no command-line examples or tool-specific instructions, and no exclusive mention of Windows tools or patterns. Linux parity is generally maintained, but the ordering could be improved.

Recommendations:

When listing tools or methods (e.g., PowerShell, Azure CLI, portal, ARM template), alternate the order or list Azure CLI before PowerShell to avoid a Windows-first impression.
Where possible, provide explicit examples for both Azure CLI and PowerShell, or clarify that both are cross-platform.
Consider adding a note that both Azure CLI and PowerShell are available on Windows, macOS, and Linux to reinforce cross-platform support.
Review other documentation pages for similar ordering or tool emphasis to ensure consistent cross-platform messaging.

Create pull request

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