Scan Details - Linux-first Docs for Azure

278

Pages Scanned

53

Pages Flagged

278

Changed Pages

19.1%

% Pages Flagged

Live Progress

🔴 Connecting...

0%

Phase: discovery

Processing: Initializing...

Activity Feed

00:00:07 Scan started

Scan Information

Started At: 2025-09-01 00:00: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:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation page demonstrates a Windows bias by primarily referencing Azure PowerShell scripts and commands for migration and preview registration, with no mention of Bash, Linux, or cross-platform CLI alternatives. The only command-line examples use PowerShell cmdlets (Set-AzContext, Get-AzProviderFeature, Register-AzProviderFeature), and the migration script is only described as a PowerShell script. There are no explicit Linux or Bash examples, and the documentation does not mention or prioritize cross-platform tools or workflows.

Recommendations:

Provide Azure CLI (az) command equivalents for all PowerShell examples, especially for migration and feature registration/unregistration.
Explicitly mention that Azure CLI is cross-platform and can be used on Linux, macOS, and Windows.
Where scripts are referenced (e.g., migration script), clarify if a Bash or cross-platform version is available, or provide one.
In 'Next steps', include links to tutorials or documentation that use Azure CLI or Bash.
When listing tools or interfaces (portal, PowerShell, CLI), avoid always listing PowerShell first; alternate or clarify cross-platform parity.
Add a note or section addressing Linux/macOS users and their options for managing Application Gateway.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a bias toward Windows by providing only a PowerShell example for resource cleanup and focusing on IIS (a Windows web server) for validation. There are no Linux/CLI/bash examples for resource deletion, nor is there mention of Linux-based web servers (such as Apache or Nginx) for backend validation. The only explicit command-line example is PowerShell, and the validation step assumes Windows VMs with IIS, omitting Linux alternatives.

Recommendations:

Provide equivalent Azure CLI and/or Bash examples for resource group deletion (e.g., az group delete --name <group-name>).
Include instructions or notes for validating the deployment using Linux VMs (e.g., with Apache or Nginx) as backend servers.
When referencing command-line tools or scripts, present both Windows (PowerShell) and Linux (CLI/bash) options, or link to relevant cross-platform documentation.
Clarify that the backend VMs can run either Windows or Linux, and provide sample templates or links for both scenarios.

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 environments, specifically IIS servers, and use Windows-specific tools such as the App Service Migration Assistant (MSI installer) and PowerShell scripts. There are no examples, tools, or guidance provided for migrating .NET apps from Linux environments (e.g., Apache, Nginx, Kestrel), nor are Linux command-line or scripting options mentioned. The documentation assumes the source environment is Windows/IIS and does not address Linux-based .NET hosting scenarios.

Recommendations:

Add migration guidance and examples for .NET apps hosted on Linux servers (e.g., Apache, Nginx, Kestrel).
Include Linux-native tools or scripts (e.g., Bash, shell scripts) for discovery, assessment, and migration.
Provide parity in documentation by listing Linux migration options alongside Windows options, not only after or as an afterthought.
Mention cross-platform migration considerations, such as differences in file paths, environment variables, and dependencies.
If certain tools are Windows-only, clearly state this and suggest alternative approaches for Linux users.
Offer containerization guidance for Linux-hosted .NET apps, not just Windows containers.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page shows subtle Windows bias, particularly in its references to Windows-centric configuration files (web.config), tools (iisnode), and the absence of Linux-specific or cross-platform alternatives in several sections. While there is a mention of Linux in the Node.js/PM2 section, most configuration and troubleshooting guidance defaults to Windows paradigms, and Linux equivalents are not consistently provided.

Recommendations:

When mentioning configuration via 'web.config', also provide equivalent instructions for Linux-based App Service (e.g., using app settings, environment variables, or other Linux-supported configuration files).
In the Node.js section, balance references to 'iisnode' (Windows-specific) with Linux-native process managers or reverse proxies (e.g., PM2, Nginx) and provide guidance for both environments.
Where troubleshooting or diagnostics steps are given, clarify any differences between Windows and Linux App Service plans, and provide examples for both.
Review all examples and recommendations to ensure Linux users are not required to infer or research their own equivalents; provide explicit Linux instructions where appropriate.
Consider adding a table or section that summarizes differences and best practices for both Windows and Linux App Service environments.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation page demonstrates a mild Windows bias. In several sections, Windows-related tools and patterns are mentioned before their Linux equivalents, such as listing 'Windows' SKU availability before 'Linux' SKU availability. The automation section provides both Azure CLI (cross-platform) and Azure PowerShell (Windows-centric) examples, but does not mention Bash scripting or Linux-specific automation. The portal instructions and screenshots are platform-neutral, but the overall structure and tool recommendations lean towards Windows users.

Recommendations:

Alternate the order of Windows and Linux instructions/examples to avoid always listing Windows first.
Include Bash or shell script automation examples alongside Azure PowerShell, especially for Linux users.
Explicitly mention that Azure CLI commands work on both Windows and Linux, and provide any Linux-specific notes if needed.
Where possible, add Linux-specific troubleshooting tips or considerations.
Ensure parity in terminology and tool recommendations for both Windows and Linux environments.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation exhibits a moderate Windows bias. Windows-specific terminology and tools (such as Azure PowerShell) are mentioned prominently, and Windows SKU availability is listed before Linux. While Azure CLI examples are provided (which are cross-platform), there are no Linux shell-specific examples or references to Linux-native scripting. The PowerShell automation section is included without a corresponding Bash or Linux shell script example. The documentation also refers to the Azure portal UI, which is platform-agnostic, but does not address Linux-specific workflows or tools.

Recommendations:

Provide Linux shell (Bash) script examples for automating tasks, alongside PowerShell.
List Linux SKU availability before or alongside Windows, or alternate their order.
Clarify that Azure CLI commands work on both Windows and Linux, and provide explicit Bash usage where appropriate.
Include references to Linux-native tools or workflows where relevant.
Ensure that all automation and scripting sections have parity between Windows (PowerShell) and Linux (Bash/CLI).

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a mild Windows bias. Windows instructions, tools, and troubleshooting steps are often presented first or exclusively, especially in troubleshooting and GUI usage. PowerShell commands are provided for connectivity testing, but equivalent Linux commands are missing. The GUI for Hybrid Connection Manager is only available on Windows, and while this is a product limitation, the documentation does not provide parity in terms of Linux troubleshooting or alternative tools. Some sections (e.g., troubleshooting) reference Windows-specific tools and patterns without Linux equivalents.

Recommendations:

When providing troubleshooting steps (e.g., testing connectivity), include Linux equivalents for PowerShell commands, such as using 'nc', 'telnet', or 'curl' for TCP connectivity tests.
In sections where Windows GUI tools are referenced, explicitly acknowledge the lack of Linux GUI and provide detailed CLI alternatives or scripts for Linux users.
Where Windows tools or patterns are mentioned (e.g., 'Test-NetConnection', 'Azure Hybrid Connection Manager Service'), provide Linux service management equivalents (e.g., 'systemctl status hcm', 'journalctl -u hcm').
Ensure that all code snippets, especially for installation and troubleshooting, are present for both Windows and Linux, or clearly state when a feature is unavailable on a platform.
Consider reordering some sections to present Windows and Linux instructions in parallel tabs or side-by-side, rather than defaulting to Windows-first presentation.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias primarily through its reliance on PowerShell scripts for advanced resource discovery and mitigation (e.g., identifying Traffic Manager endpoints). While general Azure CLI and REST API references are present, all scripting automation examples are PowerShell-based, with no Bash, shell, or cross-platform alternatives provided. There is also no explicit mention of Linux/macOS compatibility or guidance for users on those platforms.

Recommendations:

Provide equivalent Bash/shell scripts for all PowerShell automation examples, especially for identifying Traffic Manager endpoints and other resource queries.
Explicitly state whether provided PowerShell scripts are compatible with PowerShell Core on Linux/macOS, or provide guidance for running them cross-platform.
Where possible, offer Azure CLI-based alternatives for automation tasks, as Azure CLI is natively cross-platform.
Include notes or links for Linux/macOS users on how to perform the same tasks, or reference relevant documentation.
Ensure that any downloadable scripts or automation tools are tested and documented for both Windows and Linux environments.

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 web servers within VMware environments, which are inherently Windows-centric technologies. There are no references to discovering .NET web apps running on Linux (e.g., Kestrel, Apache, or Nginx), nor are there examples or guidance for Linux-based deployments. All discovery capabilities and tooling mentioned (Azure Migrate appliance, IIS) are Windows-specific, and Linux scenarios are entirely absent.

Recommendations:

Include guidance and examples for discovering .NET web apps running on Linux servers (e.g., Kestrel, Apache, Nginx).
Mention whether Azure Migrate supports Linux-based .NET app discovery, and if not, clarify this limitation.
Provide parity in documentation by listing Linux discovery steps, tools, or alternative approaches if available.
Add references to Linux migration resources or related Azure documentation for Linux-based .NET workloads.

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 examples, troubleshooting steps, and tool references (such as web.config, iisnode, node.exe, and Kudu CMD/PowerShell) are Windows-specific. There are no Linux equivalents or examples provided, and Linux-based deployment, configuration, or troubleshooting is not mentioned. Windows tools and patterns (e.g., web.config, named pipes, Win32 error codes, Kudu CMD/PowerShell) are referenced exclusively and without Linux alternatives.

Recommendations:

Add a parallel section or separate guide for Node.js on Azure App Service Linux, covering best practices and troubleshooting.
Include Linux-specific configuration and troubleshooting examples (e.g., using environment variables, PM2, NGINX/Apache, or systemd instead of iisnode/web.config).
Provide examples of accessing logs, debugging, and profiling on Linux (e.g., using SSH, Bash, Linux file paths, and Linux-native tools).
Reference Linux equivalents for Windows-specific concepts (e.g., explain how to handle process management, logging, and configuration on Linux).
Avoid assuming the use of Windows-specific tools (like Kudu CMD/PowerShell); mention Bash or SSH where appropriate.
Clarify in the introduction that the guide is Windows-specific and link to Linux-specific documentation if available.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation exhibits subtle Windows bias by referencing Windows-specific tools (Azure Storage Explorer) and providing instructions that default to Windows tabs or workflows. There are no explicit Linux or cross-platform alternatives mentioned for uploading files or generating SAS tokens, and the only tool-specific instructions link to Windows tabs. All command-line examples use Azure CLI, which is cross-platform, but the supporting tooling and workflow references are Windows-centric.

Recommendations:

Include explicit instructions or links for performing storage operations (uploading files, generating SAS tokens) using cross-platform or Linux-native tools, such as the Azure CLI, azcopy, or REST APIs.
When referencing Azure Storage Explorer, clarify its cross-platform availability and provide Linux/macOS installation and usage guidance or links.
Avoid linking only to Windows-specific tabs or sections in documentation; ensure parity by referencing or including Linux/macOS instructions where applicable.
Consider adding a section or callout for Linux/macOS users, highlighting any differences or additional steps required.
Review related documentation links to ensure they are not Windows-centric and provide balanced coverage for all major platforms.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows bias by focusing exclusively on Windows-based deployment and configuration patterns for ASP.NET apps. All runtime version examples reference Windows file paths and tools (Kudu, CMD, PowerShell), with no mention of Linux-based App Service environments or their equivalents. There are no Linux-specific instructions or examples, and Windows tools and patterns are presented as the default or only option.

Recommendations:

Add parallel instructions and examples for configuring ASP.NET apps on Linux-based App Service plans, including how to check .NET runtime versions and access diagnostic tools.
Include Linux shell (bash) commands and file paths where appropriate, especially for sections showing how to enumerate installed runtimes or access environment variables.
Mention and link to Linux-specific tools (such as SSH, bash, or Linux Kudu equivalents) alongside Windows tools like CMD and PowerShell.
Clarify in each section whether the instructions apply only to Windows App Service plans, and provide Linux alternatives if available.
Consider a table or side-by-side comparison for common tasks (e.g., setting environment variables, accessing logs) on both 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 Tomcat data sources, but the Windows section is notably more detailed and uses Windows-specific tools and patterns (PowerShell, .cmd scripts, Windows environment variables). The Windows instructions are longer, more step-by-step, and rely heavily on PowerShell scripting, while the Linux section uses standard shell scripting and Linux tools. In some places, Windows-specific patterns (like copying Tomcat to a local directory and using %LOCAL_EXPANDED%) are described in detail, and PowerShell is used for XML transforms, which may not have direct Linux equivalents. The Linux instructions are present and functional, but the Windows approach is more thoroughly documented and uses Windows-native tooling.

Recommendations:

Ensure Linux and Windows sections are equally detailed, with step-by-step instructions for both platforms.
Where PowerShell is used for Windows, provide a Bash or shell script equivalent for Linux, especially for XML transforms.
Avoid using Windows environment variable syntax (e.g., %VAR%) in general explanations; use cross-platform or platform-specific sections.
Provide parity in troubleshooting tips and automation examples for both platforms.
Highlight cross-platform tools (like Azure CLI) where possible, and ensure examples are shown for both Linux and Windows.
Consider including a summary table comparing steps for Linux and Windows to help users quickly find the relevant instructions.

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 instructions or tools (such as Kudu, Advanced Tools, and FTPS) are mentioned first or exclusively, and some explanations assume familiarity with Windows-specific patterns. There are also more detailed step-by-step instructions for Windows in some advanced scenarios (e.g., Java Flight Recorder), while Linux sections sometimes refer users to external links or provide less detail. Some tools and troubleshooting approaches (like Kudu/Process Explorer) are Windows-centric, and Linux alternatives are not always described. In a few places, Linux-specific instructions are missing or less emphasized.

Recommendations:

Ensure that for every Windows-specific tool or workflow (e.g., Kudu, FTPS, Advanced Tools), the equivalent Linux approach is described with equal detail and visibility.
When presenting examples or instructions, alternate the order (Linux first in some sections, Windows first in others) or present both simultaneously to avoid the impression of a default OS.
Expand Linux troubleshooting and diagnostic sections to match the level of detail provided for Windows, including step-by-step instructions for common tasks (e.g., finding process IDs, downloading files, using SSH instead of Kudu).
Where Windows tools are referenced (such as Kudu Process Explorer), explicitly mention the Linux alternative (e.g., SSH and ps/top commands) and provide sample commands.
Audit for any missing Linux examples, especially in advanced configuration, deployment, and diagnostics, and add them where absent.
Review language to ensure that neither OS is implied as the default or primary platform; use neutral phrasing or parallel structure.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page exhibits a Windows-first bias. Directory paths and deployment details are primarily described using Windows-style paths (e.g., D:\home\site\wwwroot), with Linux equivalents only briefly mentioned in passing. Instructions for manual deployment (such as creating directories and files) reference only Windows paths, and there are no explicit Linux or cross-platform examples for these steps. Additionally, the documentation refers to Windows-centric deployment patterns and tools (e.g., backslashes in paths, drive letters), while omitting Linux-specific instructions or examples.

Recommendations:

Provide parallel Linux examples and explicitly mention Linux directory paths (e.g., /home/site/wwwroot) wherever Windows paths are given.
When describing manual steps (such as creating directories or files), include both Windows and Linux commands (e.g., using mkdir or touch in Bash).
Avoid using only Windows-style paths and backslashes; use cross-platform path notation or provide both formats.
Clarify any platform-specific differences in deployment behavior or directory structure.
Where possible, use platform-agnostic language and examples, or clearly separate instructions for Windows and Linux environments.

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 section, where Windows tools (Visual Studio, Azure PowerShell) are listed before cross-platform or Linux-native options. Some quickstart links default to Windows or PowerShell tabs, and Linux-specific instructions are sometimes secondary or missing. The 'Next step' call-to-action also defaults to an ASP.NET (typically Windows-first) example. Other stacks (Java, Node.js, PHP) are more Linux-oriented, but the overall structure and tool recommendations often prioritize Windows or do not provide Linux parity.

Recommendations:

Ensure that for every Windows-specific tool or example (e.g., Visual Studio, Azure PowerShell), an equivalent Linux-friendly option (e.g., VS Code, Azure CLI, Bash) is provided and listed with equal prominence.
In quickstart tables, alternate the order of tool listings or group them by platform to avoid always listing Windows tools first.
Where possible, default documentation tabs and links to cross-platform or Linux options, or provide clear toggles for both environments.
Expand the use of Linux/CLI examples in .NET sections, including explicit mention of Bash and Linux development environments.
For the 'Next step' section, offer multiple language/framework options (not just ASP.NET) and ensure at least one Linux-native path is highlighted.
Audit all linked quickstarts to ensure Linux instructions are present and up-to-date, not just Windows/PowerShell.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a bias toward Windows by primarily referencing Windows-centric tools and workflows, such as Visual Studio and NuGet Package Manager, and by omitting explicit Linux or cross-platform instructions. There are no Linux-specific examples or mentions of Linux-native tools, and the instructions for package installation and deployment are oriented toward Windows users.

Recommendations:

Provide explicit Linux and cross-platform instructions for all steps, including package installation (e.g., using dotnet CLI and apt for dependencies).
Mention and demonstrate the use of cross-platform editors (e.g., VS Code) and command-line workflows alongside Visual Studio.
Include Linux-specific deployment guidance (e.g., using Azure CLI from Bash, setting environment variables via the portal or CLI, and troubleshooting on Linux).
Ensure all code and configuration examples are tested and shown in both Windows and Linux environments.
Where GUI instructions are given (e.g., right-clicking in Visual Studio), provide equivalent command-line or editor-agnostic alternatives.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a moderate Windows bias. In the prerequisites and quickstart links, 'windows' is listed as a primary tab, and there is a lack of explicit Linux-specific instructions or examples for environment variable management, deployment, or local development. The documentation refers to the Azure portal and Visual Studio (a Windows-centric tool) for deployment and configuration, but does not provide parity for Linux command-line or deployment tools. There are no PowerShell-specific commands, but the overall pattern and tool references are Windows-first.

Recommendations:

Ensure all quickstart and prerequisite links include Linux tabs/examples, not just Windows.
Provide explicit Linux (and macOS) command-line instructions for setting environment variables and deploying to Azure App Service (e.g., using Azure CLI or Bash scripts).
Mention cross-platform editors and deployment tools (such as VS Code, Azure CLI, GitHub Actions) alongside or before Visual Studio.
Include Linux-specific troubleshooting tips or notes where platform differences may arise (e.g., file permissions, environment variable syntax).
Where the Azure portal is referenced, clarify that it is platform-agnostic, and provide CLI alternatives for common tasks.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation page demonstrates a strong bias toward Windows-centric tooling and workflows. All command-line examples are provided exclusively using Azure PowerShell cmdlets, which are most commonly used in Windows environments. There are no equivalent examples for Linux-native tools such as Azure CLI or Bash scripting. The documentation does not mention or demonstrate Linux-first or cross-platform workflows, and the PowerShell section appears before any mention of ARM templates or other alternatives.

Recommendations:

Add equivalent Azure CLI (az) command examples for all PowerShell cmdlets shown, as Azure CLI is cross-platform and widely used in Linux environments.
Include Bash scripting examples where appropriate, or at least note that the steps can be performed in Bash on Linux/Mac.
Explicitly mention that per-app scaling can be configured using both PowerShell and Azure CLI, and provide links to relevant CLI documentation.
Consider reordering sections so that cross-platform or neutral options (e.g., Azure CLI, ARM templates) are presented before or alongside PowerShell.
Add a note clarifying that PowerShell is available cross-platform, but that Azure CLI may be more familiar to Linux users.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation provides both Azure CLI and Azure PowerShell examples for retrieving outbound IP addresses, but the PowerShell examples are given equal prominence to CLI, and there is no explicit mention of Linux shell or Bash alternatives for PowerShell commands. Additionally, outbound IPv6 support is noted as being available only for Windows apps, with no Linux parity or roadmap discussed. The documentation does not explicitly favor Windows tools overall, but it does not clarify that PowerShell is cross-platform or provide Linux-specific guidance where Windows-only features are mentioned.

Recommendations:

Clarify that Azure PowerShell can be run cross-platform, or explicitly note when a command is Windows-only.
Provide Bash or Linux-native command alternatives (e.g., using jq with az CLI) where PowerShell is shown, or at least note that the CLI commands work on Linux/macOS.
When mentioning features only available for Windows (such as outbound IPv6), clearly state the lack of Linux support and, if possible, provide a roadmap or alternatives for Linux users.
In sections where both Azure CLI and PowerShell are shown, consider listing CLI first, as it is cross-platform, or explicitly mention that both are supported on all platforms.
Add more explicit Linux/Bash testing examples (e.g., using dig or host in addition to nslookup, which is available on both platforms but less common on Linux).

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by referencing Windows-style paths (e.g., D:\home), focusing on Windows-specific deployment patterns, and mentioning tools and behaviors (such as Kudu/SCM and Azure Web Apps Disk Usage) that are primarily associated with Windows App Service environments. There are no Linux-specific examples or equivalent Linux paths, and Linux/container scenarios are only mentioned to state that the feature is unsupported, without offering Linux alternatives or guidance.

Recommendations:

Include Linux-specific examples and equivalent Linux filesystem paths (e.g., /home/site) where relevant.
Clarify which features and instructions apply to Windows, Linux, or both, and provide parallel guidance for Linux App Service where possible.
Mention Linux-compatible tools or commands (such as using SSH or Linux-native utilities to check disk usage) alongside Windows tools.
If a feature is unsupported on Linux, provide links or references to alternative solutions (such as App Cache) and include basic usage instructions.
Ensure that terminology and examples are inclusive of both platforms, or clearly indicate when content is Windows-only.

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 details are limited to a brief note about continuous deployment network dependencies. There are no Linux container-specific subnet/IP calculations or operational examples. The documentation also references Windows-centric features (e.g., Windows Server Active Directory, NetBIOS) in the context of unsupported features, but does not mention Linux equivalents. Additionally, the order of presentation often places Windows-related content before Linux, and there is a lack of parity in operational guidance for Linux scenarios.

Recommendations:

Add a dedicated section for Linux Containers, including subnet/IP address calculation examples and operational limits similar to the Windows Containers section.
Provide Linux-specific examples or notes where Windows-specific features are discussed (e.g., mention that Linux containers do not require extra IPs per app, or clarify Linux limitations).
Ensure that Linux and Windows scenarios are presented in parallel, with equal detail and prominence.
Include Linux command-line examples (e.g., Azure CLI, Bash) where relevant, especially in sections discussing configuration or troubleshooting.
Mention Linux authentication and networking patterns (e.g., integration with LDAP or Kerberos, if applicable) when Windows equivalents are referenced.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows-first bias in several areas: Windows paths and conventions are often mentioned before Linux equivalents, Windows-specific tools (such as MSDeploy, Web Deploy, and Kudu for Windows) are described in detail, and some settings are explained only in a Windows context or with Windows-centric examples. There are also several environment variables and features that are described primarily or exclusively for Windows, with Linux equivalents either missing, less detailed, or mentioned secondarily. In some sections, Linux-specific behaviors are described as exceptions or afterthoughts. There is a lack of parity in example commands, paths, and tool references for Linux users.

Recommendations:

For every environment variable or feature that behaves differently on Windows and Linux, provide both Windows and Linux examples side by side, including file paths, default values, and configuration nuances.
When referencing tools or deployment methods (e.g., MSDeploy, Web Deploy, Kudu), ensure that Linux equivalents (such as Oryx, ZIP deploy, or other Linux-native tools) are described with equal detail and prominence.
Avoid using Windows paths (e.g., D:\home) as the sole example; always include the Linux equivalent (/home) in the same context.
Where features are Windows-only, explicitly state the lack of Linux support and, where possible, suggest Linux alternatives or workarounds.
Reorganize sections so that Linux and Windows information is presented in parallel, rather than Windows-first with Linux as an addendum.
Add Linux/POSIX shell command examples (where relevant) alongside any PowerShell or Windows CMD examples.
Audit the documentation for any settings or behaviors that are only described for Windows and ensure Linux users have clear, actionable guidance.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page exhibits a Windows-first bias: logging features and instructions for Windows apps are presented in greater detail and before Linux equivalents. Several logging types (web server logging, detailed error messages, failed request tracing) are described as Windows-only, with no Linux alternatives or workarounds provided. Example code and tool recommendations (such as Log Parser and references to IIS/W3C log formats) are Windows-centric. Linux logging instructions are brief and lack parity in detail or features.

Recommendations:

Provide equivalent Linux/container logging features or clearly document alternatives/workarounds for Linux users.
Present Linux and Windows instructions in parallel sections or tables to avoid Windows-first ordering.
Include Linux-specific examples and code snippets (e.g., using Python logging, Node.js logging, or Linux command-line tools to access logs).
Mention cross-platform tools for log analysis instead of or alongside Windows-only tools like Log Parser.
Clarify any feature gaps for Linux and suggest best practices or third-party solutions where Azure App Service does not provide parity.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows-centric bias by emphasizing Windows-specific tools (IIS, Procdump, PowerShell), referencing Windows-only features (such as .NET Profiler for Windows), and omitting Linux-specific troubleshooting steps or examples. The Kudu console section highlights PowerShell and DOS commands, with no mention of Bash or Linux shell. There are no Linux-specific diagnostic or logging instructions, and the documentation links to Windows-focused resources.

Recommendations:

Include equivalent Linux troubleshooting steps and examples, such as using Bash in Kudu, Linux-specific diagnostic tools, and log file locations.
When mentioning PowerShell or DOS commands, also provide Bash or shell command equivalents for Linux-based App Service environments.
Reference both Windows and Linux in tool descriptions and links (e.g., Application Insights Profiler availability and setup for Linux).
Add guidance for enabling and accessing logs and diagnostics on Linux App Service plans, including differences in log formats and locations.
Ensure that external links and references (such as to Procdump or IIS features) are balanced with Linux alternatives or clearly indicate platform applicability.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation exhibits a Windows bias primarily through the use of PowerShell commands and references to Windows-centric tools (such as AzPowerShell and Azure PowerShell) in both setup and workflow examples. The authentication and setup instructions often mention PowerShell or Windows tools first or exclusively, with no explicit Linux or cross-platform shell alternatives provided. While the CI runners are set to 'ubuntu-latest', the scripts and instructions assume familiarity with PowerShell, and there are no bash or Linux-native command examples. This may hinder Linux users or those working in non-Windows environments.

Recommendations:

Provide equivalent bash or sh examples for all PowerShell commands, especially for steps like installing dependencies, authentication, and running Playwright tests.
When referencing Azure CLI or authentication, include both Azure PowerShell and Azure CLI instructions, and clarify which is cross-platform.
Avoid using PowerShell-specific syntax in generic instructions; prefer platform-agnostic commands where possible.
Explicitly mention that all steps are cross-platform, or provide separate tabs/examples for Windows (PowerShell), Linux (bash), and macOS where relevant.
For CI workflow YAML, show both PowerShell and bash script blocks, or use shell: bash for Linux runners.
Ensure that all tool references (such as 'AzPowerShell') are accompanied by their Linux/macOS equivalents or alternatives.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a moderate Windows bias. Visual Studio Code (VS Code) is the only editor/IDE mentioned for graphical test running, and all screenshots and UI instructions are based on the Azure Portal, which is most commonly accessed from Windows environments. The .NET/NUnit example uses PowerShell syntax for package installation and does not provide a Linux/Unix alternative. There are no explicit Linux-specific instructions, terminal commands, or references to Linux-native tools or editors (such as VS Code on Linux, JetBrains Rider, or CLI-only workflows). The documentation assumes familiarity with Windows-centric tools and patterns, and does not provide parity for Linux users in terms of setup, environment variable configuration, or test running outside the VS Code ecosystem.

Recommendations:

Include explicit Linux/Unix shell command equivalents for all PowerShell or Windows CLI commands (e.g., use 'dotnet add package ...' and 'export VAR=...' in bash).
Mention that Visual Studio Code is cross-platform, and provide instructions or screenshots for Linux/macOS users where applicable.
Add examples for setting environment variables in Linux/macOS shells (e.g., 'export PLAYWRIGHT_SERVICE_URL=...').
Reference Linux-native editors or CLI workflows for running and debugging tests, not just Visual Studio Code.
Clarify that the Azure Portal is web-based and accessible from any OS, and provide any OS-specific caveats if relevant.
Ensure all code snippets and setup steps are presented in both Windows and Linux/macOS variants, especially for .NET/NUnit and Playwright CLI usage.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation, while claiming support for both Windows and Linux, displays several Windows-centric biases. Windows terminology, tools, and examples are often presented first or exclusively, such as detailed registry key monitoring (Windows-only), alerting examples focused on Windows file paths, and references to Windows services. Linux equivalents (like daemons or configuration files) are mentioned but not explored with the same depth or specificity. Some sections, such as registry tracking, are Windows-only without parallel Linux content. Command-line examples use PowerShell syntax and Windows paths, and alerting queries are Windows-heavy. Linux features and limitations are mentioned but not detailed or exemplified to the same extent.

Recommendations:

Provide Linux-specific examples and explanations wherever Windows examples are given (e.g., track /etc/passwd or /etc/ssh/sshd_config changes, monitor systemd services).
Balance the order of presentation so that Linux and Windows are treated equally (alternate or parallel sections/examples).
Include Linux-specific alerting queries and scenarios (e.g., tracking changes to /etc/hosts, /etc/systemd/system/*.service, or installed packages).
Expand on Linux limitations and supported features to match the detail given for Windows (e.g., which Linux configuration files or daemons are tracked by default).
Avoid using only Windows-centric terminology (like registry, services) without also referencing Linux equivalents (like configuration files, daemons) in the same context.
Where PowerShell or Windows CLI is used, provide Bash or Linux CLI equivalents.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation provides instructions for setting environment variables on Windows (cmd and PowerShell) before Linux/macOS (bash), and includes Windows-specific tools (setx, PowerShell syntax) prominently. Linux/macOS instructions are present but appear after Windows, and there are no Linux-specific troubleshooting tips or parity notes. The overall flow and examples are otherwise cross-platform, but the ordering and prominence of Windows tools may subtly bias toward Windows users.

Recommendations:

Present Linux/macOS and Windows instructions in parallel tabbed sections, or alternate the order to avoid always listing Windows first.
Use neutral, cross-platform language where possible (e.g., 'set the environment variable' with tabs for each OS).
Add Linux-specific troubleshooting or tips where relevant (e.g., shell persistence of environment variables).
Consider including a note that all Go code and Azure CLI commands are cross-platform.
Avoid using Windows-specific tools (like setx) without equivalent Linux/macOS context (e.g., mention ~/.bashrc for persistence).

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation provides both Azure CLI and Azure PowerShell examples for configuring active geo-replication, but does not include any Linux- or Unix-specific shell examples (e.g., Bash). PowerShell, which is traditionally associated with Windows, is given equal prominence to the Azure CLI, and there are no explicit Linux command-line or scripting examples. The documentation does not mention Linux tools or patterns, and all portal instructions are platform-agnostic, but the scripting focus is on Windows-centric tools.

Recommendations:

Add explicit Bash shell examples for Azure CLI commands, showing usage in a typical Linux environment (e.g., with environment variables, piping, or jq for output parsing).
Clarify that Azure CLI commands are cross-platform and can be run on Linux, macOS, and Windows, possibly providing a note or section on installing and using Azure CLI on Linux.
If PowerShell is included, consider mentioning PowerShell Core (pwsh) for cross-platform compatibility, or clarify when examples are for Windows PowerShell vs. PowerShell Core.
Include troubleshooting or scripting tips relevant to Linux users (e.g., using shell scripts to automate cache creation or monitoring).
Ensure parity in documentation by providing at least one end-to-end example using a Linux shell environment.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation exhibits a mild Windows bias. Windows-specific tools, settings, and instructions are often mentioned before or more prominently than their Linux equivalents. Some sections provide only Windows or PowerShell examples, or list Windows tooling before Linux/CLI alternatives. Linux-specific instructions are present but sometimes secondary or less detailed. There are also places where Linux examples or parity could be improved, especially regarding deployment, configuration, and debugging.

Recommendations:

Ensure that all CLI and deployment instructions are presented with both Windows (PowerShell/CMD) and Linux (Bash/CLI) examples, or use cross-platform Azure CLI examples by default.
When listing tooling or setup methods (e.g., Visual Studio, VS Code, CLI), avoid always listing Windows-first; alternate the order or group by platform.
Where PowerShell is mentioned, provide equivalent Bash or shell commands for Linux users.
In sections discussing configuration (e.g., environment variables, app settings), explicitly show both Windows and Linux syntax or reference platform-agnostic approaches.
For debugging and local development, include Linux-specific guidance and troubleshooting steps, not just Visual Studio/Windows workflows.
In performance and deployment optimization sections (e.g., ReadyToRun, runtime identifiers), ensure Linux instructions are as detailed as Windows, including explicit Linux examples for project files and CLI commands.
Review all code snippets and ensure any that are platform-specific are clearly labeled, and that Linux alternatives are provided where relevant.
Consider adding a parity checklist to ensure future documentation updates maintain equal coverage for Linux and Windows scenarios.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias by prioritizing Windows-centric tools and workflows (such as Visual Studio Code, Azurite emulator, and PowerShell), and by omitting explicit Linux/macOS command-line instructions or alternatives. The use of PowerShell as a language example and the assumption of Visual Studio Code as the primary environment further reinforce this bias. There are no explicit instructions for Linux/macOS users regarding starting Azurite, running the function app, or managing dependencies, and the documentation does not mention platform-specific differences or alternatives.

Recommendations:

Provide explicit instructions for Linux/macOS users, including terminal commands for starting Azurite and running the function app.
Include bash/zsh shell command examples alongside PowerShell where applicable.
Clarify that Visual Studio Code and Azurite are cross-platform, and provide installation or usage notes for Linux/macOS.
Add notes about any platform-specific differences in file paths, environment variable configuration, or command usage.
Where PowerShell is used as a language example, ensure parity by providing bash or shell script equivalents, or clarify that the example is cross-platform if applicable.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation demonstrates a moderate Windows bias. Windows-based build agents (vmImage: 'windows-latest') are used by default for C# and PowerShell examples, and Windows is the default appType for deployment. PowerShell is included as a first-class language, but Linux shell scripting is only shown for JavaScript and Python. In deployment examples, Windows is presented first, and Linux options are secondary or require explicit configuration. There is little mention of Linux-native tooling or patterns outside of specifying 'ubuntu-latest' for some languages.

Recommendations:

For C# and PowerShell, provide both Windows and Linux build pipeline examples, or clarify when Linux is supported.
Present Linux and Windows deployment examples side-by-side, rather than defaulting to Windows.
Highlight Linux-native tools or patterns where appropriate (e.g., bash for PowerShell alternatives, or cross-platform scripting).
Clarify the support matrix for each language and platform early in the documentation.
Avoid language such as 'default is Windows' without immediately showing the Linux equivalent.
For PowerShell, note if cross-platform PowerShell Core is supported and provide Linux agent examples if possible.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation generally aims for cross-platform parity, but there are subtle signs of Windows bias. Command-line examples are consistently split between Bash and Cmd, but Windows (Cmd) examples are always presented alongside or immediately after Bash, sometimes with more detailed context. There are no PowerShell-specific examples, but the presence of Windows command prompt (Cmd) examples throughout, and the explicit mention of 'command prompt' in getting started sections, may suggest a Windows-first mindset. There are no Linux-specific troubleshooting or environment notes, and some sections (such as environment variable configuration) assume familiarity with Windows conventions. No Linux-specific tools or shell environments (e.g., zsh, fish) are mentioned, and there are no explicit Linux troubleshooting steps or caveats.

Recommendations:

Ensure that Bash examples are always presented first, and clarify that Bash commands work on Linux, macOS, and Windows (with WSL or Git Bash).
Add explicit notes or sections for Linux users, such as common locations for JAVA_HOME, shell profile configuration, or troubleshooting tips for Linux environments.
Where 'command prompt' is mentioned, also mention 'terminal' or 'shell' to be inclusive of Linux/macOS users.
Include Linux-specific troubleshooting steps or caveats where relevant (e.g., file permissions, case sensitivity, environment variable export syntax).
Consider referencing cross-platform shells (e.g., zsh, fish) or tools (e.g., SDKMAN for Java version management) where appropriate.
Review all examples and ensure parity in detail and context between Bash and Cmd sections.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation page exhibits a moderate Windows bias, particularly in its developer guidance and code examples. PowerShell is highlighted in notes and examples, and references to Windows-centric tools and patterns (such as Visual Studio and System Center Operations Manager) are prevalent. While Azure CLI is mentioned, PowerShell is often given equal or greater prominence, and Linux-specific guidance or examples are largely absent.

Recommendations:

Provide Linux/bash shell equivalents for all PowerShell code examples, especially in sections where Azure CLI is mentioned.
Include explicit references to cross-platform tools and workflows (e.g., VS Code, Azure CLI on Linux/macOS) alongside Windows tools like Visual Studio.
When listing command-line options, present Azure CLI (which is cross-platform) before PowerShell, or at least in parallel, to avoid the perception of Windows-first bias.
Add guidance or links for Linux/macOS users where configuration or SDK endpoint changes are discussed, ensuring parity in instructions.
Review sections referencing Windows-specific management tools (e.g., System Center Operations Manager, Visual Studio) and add alternatives or notes for Linux-based management and development environments.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows bias by providing detailed PowerShell instructions and command tables, while omitting equivalent Linux/bash examples. The PowerShell section is more extensive and explicit, and there are no references to Linux-native tools or shell environments. The Azure CLI section is present but minimal, and there are no examples or guidance for Linux-specific workflows or tools. The documentation assumes familiarity with Windows-centric tools and patterns, potentially disadvantaging Linux users.

Recommendations:

Add explicit Linux/bash examples for connecting to Azure Government, including shell commands and environment variable settings.
Provide parity in step-by-step instructions for both PowerShell (Windows) and bash (Linux/macOS) environments.
Include references to Linux-native tools (e.g., curl, jq) for REST API access and scripting.
Ensure that Azure CLI examples are as detailed as PowerShell examples, including authentication and environment configuration steps.
Reorganize sections so that CLI/bash and PowerShell instructions are presented with equal prominence, or alternate which comes first.
Add a note clarifying cross-platform compatibility and any OS-specific considerations.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation page for creating an SMB volume in Azure NetApp Files demonstrates a Windows-centric bias. All examples and instructions for managing SMB permissions and shares are exclusively presented using Windows tools (MMC, Windows SMB client), with no mention of Linux or cross-platform alternatives. The workflow assumes the use of Windows environments and omits guidance for Linux users who may need to access or manage SMB shares.

Recommendations:

Include examples and instructions for accessing and managing SMB shares from Linux clients (e.g., using smbclient, mount.cifs, or Linux file managers).
Provide guidance on setting SMB permissions from Linux systems, such as using setfacl or smbclient's 'chmod' and 'chown' commands where applicable.
Mention and document cross-platform tools and approaches for SMB management, ensuring parity for Linux and macOS users.
Rephrase sections that refer to 'Windows SMB client' or 'Windows File Browser' to include Linux and macOS equivalents, or clarify that the instructions are specific to Windows and provide links to Linux/macOS documentation.
Add troubleshooting and best practices for Linux SMB clients, including known compatibility notes and mount options.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation provides mounting instructions for both Linux and Windows clients, but there are subtle biases. The Windows section is presented after the Linux section, but the Windows mounting example references a prerequisite step that must be performed on a Unix/Linux VM (chmod), which may not be intuitive for Windows-only administrators. The Windows example references the Windows 'Mount' command but does not provide a PowerShell example or alternative. The Linux section is more detailed and includes explicit mount command examples, while the Windows section is less comprehensive and omits troubleshooting or advanced options. There is also a lack of parity in the depth of guidance for each platform.

Recommendations:

Provide a more detailed Windows mounting section, including troubleshooting tips and advanced mount options similar to the Linux section.
Offer PowerShell examples for Windows users, not just the legacy 'Mount' command.
Clarify the cross-platform prerequisite (chmod on Linux/Unix) for Windows administrators, and suggest alternatives if the user does not have access to a Linux VM.
Ensure that both Linux and Windows sections include comparable detail, including fstab (Linux) and persistent mount (Windows) instructions.
Consider reordering or clearly separating platform-specific instructions to avoid confusion and ensure parity.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by providing only Azure PowerShell examples for feature registration, mentioning PowerShell commands before Azure CLI alternatives, and omitting explicit Linux/bash command-line examples. The UI instructions also use Windows-centric terminology (e.g., 'right-click'), and there are no screenshots or walkthroughs for Linux or cross-platform CLI usage.

Recommendations:

Provide explicit Azure CLI (bash) examples alongside PowerShell for all registration and configuration steps, including full command syntax and expected output.
Present Azure CLI examples before or alongside PowerShell to avoid Windows-first ordering.
Include notes or sections clarifying that all operations can be performed from Linux/macOS environments using Azure CLI.
Replace or supplement 'right-click' UI instructions with cross-platform alternatives (e.g., 'select the options menu' or 'open the context menu'), and clarify that the Azure Portal is web-based and OS-agnostic.
Add screenshots or walkthroughs demonstrating CLI usage from Linux/macOS terminals.
Where relevant, mention any OS-specific considerations or parity between Windows and Linux management tools.

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 guidance for assessing .NET web apps running on Linux or using cross-platform tools. All referenced materials and terminology (such as ASP.NET) suggest a Windows-centric approach, with no mention of Linux-based .NET Core or cross-platform assessment scenarios.

Recommendations:

Include explicit guidance and examples for assessing .NET web apps running on Linux (e.g., ASP.NET Core on Linux).
Mention and provide parity for Linux-compatible assessment tools or scripts, if available.
Clarify whether the assessment process and recommendations apply to both Windows and Linux-hosted .NET apps.
Add references to documentation or tutorials for Linux-based .NET app migration and assessment.
Use cross-platform terminology (e.g., '.NET web apps' instead of only 'ASP.NET web apps') where appropriate.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows-first bias by referencing the Windows deployment path (C:\home\site\wwwroot) and providing a relative path example for Windows before mentioning Linux. The Linux-specific requirement (absolute path) is only mentioned in a note, and no Linux file system example is given in the main steps. There are no Linux command-line or file management examples, and the documentation assumes familiarity with Windows paths and conventions.

Recommendations:

Provide Linux file path examples (e.g., /home/site/wwwroot/auth.json) alongside Windows examples in all relevant steps, not just in notes.
Explicitly mention both Windows and Linux deployment scenarios in the main instructions, not only in side notes.
Include Linux command-line examples (e.g., using cp, mv, or editors like nano/vim) for creating and deploying the configuration file.
Clarify any platform-specific differences in configuration up front, rather than as afterthoughts or notes.
Ensure parity in guidance for both Windows and Linux users, including screenshots or terminal snippets where appropriate.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows/Azure portal bias by exclusively describing configuration steps through the Azure portal UI, which is most familiar to Windows users. There are no command-line examples (such as Azure CLI, Bash, or PowerShell), and no mention of Linux-native workflows or tools. The absence of Linux command-line instructions or parity for headless/server environments is notable.

Recommendations:

Add equivalent instructions using Azure CLI commands, which are cross-platform and commonly used in Linux environments.
Include examples for configuring authentication via ARM templates or Bicep, which can be used on any platform.
Explicitly mention that the Azure portal is web-based and platform-agnostic, but provide links or examples for users who prefer command-line or automated approaches.
Provide sample scripts for updating app settings (such as GITHUB_PROVIDER_AUTHENTICATION_SECRET) using Bash or PowerShell, and clarify that these can be run on both Windows and Linux.
Ensure that any references to tools or workflows are balanced between Windows and Linux, or are clearly cross-platform.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page presents Windows containers first and provides more straightforward instructions for Windows (no modifications needed, browser SSH only), while Linux containers require additional configuration and have more detailed, step-by-step CLI instructions. There are no PowerShell or Windows CLI examples, but Linux is treated as the more complex case, and the Windows section lacks parity in terms of CLI-based SSH access examples.

Recommendations:

Present Linux and Windows instructions in parallel or in a neutral order, rather than always listing Windows first.
Provide equivalent CLI-based SSH access instructions for Windows containers, or explicitly state if such functionality is not available.
If Windows CLI/PowerShell SSH access is not supported, clarify this limitation and suggest any available alternatives.
Ensure both Linux and Windows sections have comparable depth and detail in their instructions and troubleshooting steps.
Consider adding a summary table comparing SSH access methods and requirements for both Linux and Windows containers.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation assumes a development environment that is platform-agnostic (using GitHub Codespaces and .NET CLI), but it lacks explicit Linux-specific instructions or examples. There is a subtle Windows-first bias in that the .NET ecosystem and Azure App Service are more commonly associated with Windows, and there are no mentions of Linux-specific deployment, troubleshooting, or command-line differences. No PowerShell or Windows-only tools are shown, but the absence of Linux terminal or shell examples (e.g., bash) and lack of mention of Linux App Service plans or differences constitutes a 'missing_linux_example' bias.

Recommendations:

Explicitly mention that all .NET CLI commands work on Linux, macOS, and Windows, and show example terminal prompts for bash/zsh as well as Windows CMD/PowerShell if relevant.
Include a note or section about deploying to Azure App Service (Linux) and any differences in configuration or troubleshooting.
If referencing file paths, show both Windows (\) and Linux (/) path formats.
If using Codespaces, clarify that the environment is Linux-based and that all steps are cross-platform.
Add troubleshooting tips for common Linux-specific issues (e.g., file permissions, case sensitivity, environment variables).

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation focuses exclusively on ASP.NET Core and .NET tooling, referencing only Windows-centric development patterns (such as editing launchSettings.json and using Visual Studio project structure). There are no Linux-specific instructions or examples, and the workflow assumes familiarity with Windows development environments.

Recommendations:

Include explicit instructions for setting environment variables on Linux/macOS (e.g., using export in the terminal or configuring environment variables in launch scripts).
Mention how to run and debug the application using common Linux editors (like VS Code) or command-line tools, not just through launchSettings.json.
Clarify that the dotnet CLI is cross-platform, and provide terminal commands for both Windows (cmd/PowerShell) and Linux/macOS (bash/zsh).
Add a note or section about file path differences and environment variable conventions between Windows and Linux.
Provide screenshots or examples that reflect Linux/macOS environments in addition to Windows.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation demonstrates a mild Windows bias. While installation instructions are provided for both Linux and Windows, the Windows section directs users to install WSL (Windows Subsystem for Linux) rather than providing a native Windows redis-cli solution or mentioning third-party Windows builds. Additionally, throughout the document, references to Windows tools (such as Windows Terminal and WSL) are made, and the Azure PowerShell method is mentioned alongside the Azure CLI for retrieving cache keys, which may reinforce a Windows-centric workflow.

Recommendations:

Provide explicit instructions or references for native Windows redis-cli binaries or trusted third-party builds, if available, rather than only recommending WSL.
Present Linux and Windows installation instructions with equal detail and prominence, possibly side-by-side.
When listing methods to retrieve cache keys, mention Azure CLI (cross-platform) before Azure PowerShell (Windows-centric), or clarify that both are available on all major platforms.
When referencing terminals, mention cross-platform options (e.g., Windows Terminal, GNOME Terminal, macOS Terminal) rather than focusing on Windows tools.
Explicitly state that redis-cli commands are the same across platforms to reinforce parity.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

Summary:

The documentation provides examples for scaling Azure Cache for Redis using the Azure portal, Azure PowerShell, and Azure CLI. However, PowerShell examples are consistently presented before Azure CLI examples, and there is a notable emphasis on PowerShell cmdlets throughout the document. There are no explicit Linux-specific tools or shell examples (such as Bash), and the CLI examples are not contextualized for Linux users. This ordering and focus may implicitly favor Windows users and workflows.

Recommendations:

Alternate the order of PowerShell and Azure CLI examples, or present Azure CLI examples first to avoid implicit prioritization of Windows tools.
Explicitly mention that Azure CLI commands work cross-platform (Windows, Linux, macOS) and provide Bash shell context where appropriate.
Add Linux/Bash-specific example blocks or notes, especially for common scenarios such as scripting or automation.
Consider including a table or section summarizing tool availability and usage across different operating systems.
Where PowerShell is referenced, clarify that PowerShell Core is available cross-platform, or provide equivalent Bash commands if possible.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation is generally cross-platform and Linux-focused for hosting, but there are subtle Windows biases in the development and publishing workflow sections. Specifically, Windows is mentioned first or as the default in several places (e.g., 'command prompt', 'developing on Windows', 'use remote build when developing Python apps on Windows'), and there is a lack of explicit Linux shell examples (e.g., bash/zsh) in command snippets. The term 'command prompt' is ambiguous and can be interpreted as Windows-centric. Visual Studio Code is referenced as a primary tool, which is cross-platform, but no mention is made of Linux-specific editors or shell environments. The documentation does not provide PowerShell-specific examples, but the ordering and language suggest a slight preference for Windows development environments.

Recommendations:

Replace ambiguous terms like 'command prompt' with 'terminal (Bash, zsh, or Command Prompt)' and provide explicit bash/zsh examples alongside any Windows-specific instructions.
When mentioning development environments, list Linux terminals and shells (e.g., Bash, zsh) before or alongside Windows Command Prompt to avoid 'windows_first' bias.
In publishing and build workflow sections, clarify that both Windows and Linux are supported for local development and publishing, and provide shell-agnostic or dual examples (e.g., both bash and cmd).
Highlight Linux-native editors (e.g., Vim, Emacs, GNOME Terminal) as alternatives to Visual Studio Code, or at least acknowledge their use.
Where remote build is recommended for Windows, also provide guidance for Linux users, ensuring parity in workflow descriptions.
Audit all command snippets to ensure they are not Windows-centric (e.g., avoid using only .cmd file extensions or Windows path separators).

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation page exhibits mild Windows bias by referencing Windows-specific documentation first when describing how to create a Proximity Placement Group (PPG), specifically linking to the Azure portal instructions under a Windows path. There are no Linux-specific examples, links, or references, and the documentation does not mention Linux tools or workflows, even though SAP HANA is commonly deployed on Linux. However, the bias is limited, as most of the content is platform-agnostic and does not provide command-line examples for either OS.

Recommendations:

When linking to Azure portal instructions, use OS-neutral documentation paths or include both Windows and Linux links (e.g., /azure/virtual-machines/linux/proximity-placement-groups-portal and /azure/virtual-machines/windows/proximity-placement-groups-portal).
Explicitly mention that the instructions apply to both Windows and Linux SAP HANA deployments, or clarify any OS-specific considerations.
If providing command-line or script examples in the future, ensure parity by including both PowerShell (Windows) and Bash/Azure CLI (Linux) examples.
Reference Linux-specific documentation or best practices where relevant, especially since SAP HANA is predominantly deployed on Linux.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation is structured to present Windows and SQL Server solutions before Linux equivalents in several sections, and Windows-specific tools and patterns (such as DFS Namespaces and FSLogix) are referenced without always providing Linux alternatives. While Linux workloads are well-represented, there is a tendency to mention or prioritize Windows technologies and tools, especially in file sharing, SAP, and Virtual Desktop Infrastructure contexts.

Recommendations:

Ensure Linux and Windows solutions are presented with equal prominence and in parallel where possible, rather than grouping all Windows solutions together before Linux or vice versa.
For every Windows-specific tool or pattern mentioned (e.g., DFS Namespaces, FSLogix), include Linux/NFS alternatives and best practices, or explicitly state if there is no direct Linux equivalent.
When referencing file sharing or backup/restore patterns, provide both SMB (Windows) and NFS (Linux) guidance and examples.
In SAP and Virtual Desktop Infrastructure sections, clarify which solutions are Windows-only and which are cross-platform, and add Linux VDI examples if supported.
Review the order of solution listings to avoid implicit prioritization of Windows over Linux, or alternate the order in different sections.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

Summary:

The documentation page demonstrates a mild Windows bias by providing an Azure PowerShell example for checking feature registration status, with the Azure CLI (cross-platform) option mentioned only secondarily and without a full example. There are no explicit Linux shell or command-line examples, and the only code block is PowerShell. However, the page does reference Linux-specific performance benchmarks, and there is no mention of Windows-only tools or patterns beyond the PowerShell example.

Recommendations:

Provide both Azure PowerShell and Azure CLI command examples side by side, with equal prominence and full syntax for each.
Include Linux shell (bash) command examples where relevant, especially for tasks like feature registration or querying status.
When listing command-line options, alternate the order (e.g., sometimes present CLI before PowerShell) or present them in parallel.
Explicitly state that both Windows and Linux administrators can perform all tasks, and link to platform-specific guidance if available.
Review other sections for implicit assumptions about the user's platform and ensure parity in instructions and tooling.

Create pull request

Bias Types:

⚠️ missing_linux_example

Summary:

The documentation does not display explicit Windows bias in terms of command-line tools or PowerShell usage, nor does it mention Windows-specific tools or patterns. However, it lacks explicit Linux (or macOS) examples, such as bash/zsh shell commands, Linux-specific configuration notes, or references to platform-specific considerations. The examples provided are platform-neutral (TypeScript and C#), but the absence of Linux/macOS-specific guidance or validation may leave Linux users uncertain about compatibility or required adjustments.

Recommendations:

Add explicit Linux/macOS command-line examples (e.g., bash/zsh usage) alongside the current examples.
Include a note confirming cross-platform compatibility, or highlight any platform-specific considerations for Linux/macOS users.
If there are any differences in environment setup or file paths between Windows and Linux/macOS, document them clearly.
Consider providing a Linux/macOS-specific section or callout to reassure non-Windows users that the instructions apply to their platforms.

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation page lists configuration provider libraries for multiple languages and platforms, but the ordering and emphasis place .NET (a Windows-centric ecosystem) and related Microsoft technologies first, before Java, Python, JavaScript, and Go. There are no explicit Windows-only tools or PowerShell examples, but the .NET focus and ordering may implicitly prioritize Windows development environments.

Recommendations:

Reorder the provider library table to avoid always listing .NET/Microsoft-first; consider alphabetical or usage-based ordering.
Explicitly mention cross-platform compatibility for .NET libraries (e.g., .NET Core runs on Linux/macOS).
Add a note clarifying that all listed providers are supported on both Windows and Linux where applicable.
If possible, provide Linux/macOS-specific usage notes or samples, especially for .NET and Java providers.
Ensure that future documentation and examples do not assume a Windows environment by default.

Create pull request

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