Scan Details - Linux-first Docs for Azure

197

Pages Scanned

42

Pages Flagged

197

Changed Pages

21.3%

% Pages Flagged

Live Progress

🔴 Connecting...

0%

Phase: discovery

Processing: Initializing...

Activity Feed

00:01:01 Scan started

Scan Information

Started At: 2025-08-31 00:01:01

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_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by primarily referencing Azure PowerShell scripts and cmdlets for migration and preview registration tasks, with no equivalent Bash or Linux-native CLI examples. The 'Next steps' and migration sections highlight PowerShell before Azure CLI or Linux-friendly tooling, and all code snippets use PowerShell syntax. There are no explicit Linux/Bash examples or mentions of Linux-specific tools or workflows.

Recommendations:

Provide equivalent Azure CLI (bash) examples alongside or before PowerShell scripts for all operations, especially migration and preview registration.
Explicitly mention that all features and scripts are cross-platform where applicable, and clarify any OS-specific limitations.
In the 'Next steps' and tutorial links, ensure parity by linking to both PowerShell and Azure CLI (bash) tutorials.
Where PowerShell is referenced, add a note or section for Linux/macOS users on how to perform the same tasks using Azure CLI or Bash.
Review all code blocks and add bash/CLI alternatives, using code block annotations (e.g., ```azurecli or ```bash) to distinguish them.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a bias towards Windows environments by providing only a PowerShell example for resource cleanup and referencing IIS (a Windows-only web server) for validation. There are no equivalent Linux/bash/CLI examples for resource deletion, nor is there mention of Linux-based web servers for validation. The use of Windows-centric tools and lack of Linux parity may hinder users on non-Windows platforms.

Recommendations:

Provide equivalent Azure CLI (bash) commands for resource cleanup, such as 'az group delete --name <your resource group name>'.
Include validation steps using a Linux-based web server (e.g., Nginx or Apache) in addition to IIS, or clarify that the template can be modified to deploy Linux VMs.
Ensure that all PowerShell examples are accompanied by Azure CLI/bash equivalents, especially for common tasks like resource deletion.
Explicitly mention cross-platform options and link to relevant Linux/CLI documentation where appropriate.

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, with no mention of Linux-based web servers or cross-platform migration scenarios. PowerShell scripts are the only automation method referenced, and all downloadable tools are for Windows. There are no Linux or cross-platform migration tools, examples, or guidance provided.

Recommendations:

Include migration scenarios and tools for Linux-based .NET web apps (e.g., apps hosted on Apache, Nginx, or Kestrel on Linux).
Provide Linux shell (bash) script equivalents for PowerShell automation tasks.
Mention and document any cross-platform or Linux-compatible migration tools, or clarify if such tools do not exist.
Add examples and walkthroughs for migrating .NET apps from Linux environments to Azure App Service.
Ensure that documentation tables and tool lists explicitly state platform compatibility and provide parity where possible.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation page demonstrates subtle Windows bias by referencing Windows-specific tools (such as web.config and iisnode) without providing equivalent Linux-native guidance or examples. The configuration and troubleshooting sections mention Windows-centric patterns first or exclusively, and there is a lack of parity in examples or instructions for Linux-based App Service environments.

Recommendations:

For features like auto-healing, provide Linux-native configuration guidance (e.g., reference app settings, environment variables, or Linux-specific config files) alongside web.config instructions.
When mentioning iisnode or web.config for Node.js apps, include equivalent Linux process managers (such as PM2, systemd, or environment-based configuration) and clarify which settings apply to Linux vs. Windows App Service.
Add explicit Linux examples or notes in all sections where only Windows tools or patterns are mentioned, ensuring that users running on Linux App Service have clear, actionable instructions.
Review and update troubleshooting and best practices sections to ensure both Windows and Linux App Service environments are addressed equally, ideally with side-by-side examples.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation demonstrates a mild Windows bias by presenting Windows-related information and tools before their Linux equivalents. For example, in the 'Premium V3 availability' section, the Windows SKU availability command is listed before the Linux command. The automation section provides both Azure CLI and Azure PowerShell examples, but PowerShell (a Windows-centric tool) is given equal prominence, and no Linux shell-specific scripting (e.g., bash) is shown. The UI walkthroughs and screenshots are based on the Azure Portal, which is platform-agnostic, but there are no explicit Linux-native instructions or examples beyond the CLI command with --linux-workers-enabled.

Recommendations:

Present Linux and Windows options in parallel or alternate their order to avoid always listing Windows first.
Include bash or shell script examples for Linux users alongside PowerShell examples.
Explicitly mention that Azure CLI commands work cross-platform, and provide examples of running them in both Windows and Linux environments.
Where possible, add screenshots or notes relevant to Linux users (e.g., using Azure CLI in a Linux terminal).
Clarify in the automation section that PowerShell is optional and not required for Linux users.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias by frequently presenting Windows-related information and tools before Linux equivalents, providing PowerShell automation examples but omitting Bash/Linux shell examples, and referencing Windows-specific patterns and terminology. While Linux is mentioned, there is a lack of parity in scripting examples and some instructions are more detailed for Windows users.

Recommendations:

Provide Bash or shell script examples alongside PowerShell for automation, especially in the 'Automate with scripts' section.
Ensure that Linux-specific instructions (such as for custom containers) are as detailed as Windows instructions.
When listing availability or features, avoid listing Windows first by default; alternate or provide both together.
Clarify any differences in behavior or limitations for both Windows and Linux, not just Windows.
Include screenshots or walkthroughs for Linux-based workflows where applicable, not just portal-based or Windows-centric flows.

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 the GUI and PowerShell) are often mentioned first or exclusively, with Linux alternatives provided later or not at all. Troubleshooting and connectivity testing examples use Windows-specific tools (e.g., PowerShell's Test-NetConnection) without equivalent Linux commands. The Hybrid Connection Manager GUI is only available on Windows, and this is not always clearly signposted early. Some management and troubleshooting steps assume a Windows environment, and Linux users are sometimes directed to less-featured CLI alternatives.

Recommendations:

Ensure all command-line examples (e.g., connectivity tests) are provided for both Windows (PowerShell) and Linux (bash), such as including 'nc', 'curl', or 'telnet' commands alongside 'Test-NetConnection'.
When listing instructions or tools, avoid always listing Windows first; alternate or present both platforms in parallel.
Clearly state at the top of relevant sections when a feature (like the GUI) is Windows-only, and provide equivalent CLI workflows for Linux users.
In troubleshooting sections, provide Linux-native diagnostic steps (e.g., 'nslookup', 'dig', 'nc', 'curl') alongside Windows ones.
Where screenshots or UI steps are Windows-only, provide CLI or text-based alternatives for Linux users.
Review for any missing Linux-specific guidance, especially for installation, upgrades, and management, and ensure parity with Windows instructions.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation page shows a moderate Windows bias, particularly in its guidance for identifying impacted resources. PowerShell scripts are recommended and detailed for key scenarios (e.g., identifying Traffic Manager endpoints), but there are no equivalent Bash, Azure CLI, or cross-platform script examples. The only scripting guidance for deep configuration checks points to PowerShell scripts, and instructions for running them assume a Windows/PowerShell environment. While Azure CLI and REST API references are present for certificate management, the diagnostic and automation examples are Windows-centric, and Linux/macOS users are left without parity.

Recommendations:

Provide equivalent Bash or cross-platform (e.g., Python, Azure CLI) scripts for all PowerShell script recommendations, especially for identifying Traffic Manager endpoints and retrieving site config values.
When referencing scripts, clarify platform compatibility and offer both Windows (PowerShell) and Linux/macOS (Bash/CLI) options.
Include explicit Azure CLI examples for all automation and diagnostic tasks, not just for certificate management.
Avoid assuming the user has access to PowerShell or a Windows environment; mention how Linux/macOS users can achieve the same results.
Where possible, link to or provide scripts that can be run in Azure Cloud Shell, which supports both Bash and PowerShell, and clarify usage for both shells.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation exclusively discusses discovery of .NET web apps deployed on IIS web servers within VMware environments, which are Windows-specific technologies. There are no mentions of Linux-based web servers (such as Apache or Nginx), nor are there any examples or guidance for discovering .NET apps running on Linux. All tools and patterns referenced (IIS, Azure Migrate appliance for IIS) are Windows-centric.

Recommendations:

Include information on discovering .NET web apps hosted on Linux servers, such as those running on Apache, Nginx, or Kestrel.
Provide equivalent discovery steps, tooling, or references for Linux environments.
Add examples or case studies for .NET Core/ASP.NET Core apps deployed on Linux, reflecting modern cross-platform .NET usage.
Clarify in the introduction if the discovery process is currently limited to IIS/Windows, and provide a roadmap or links for Linux support if available.

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, troubleshooting, and examples are tailored to Windows, referencing Windows-specific tools (e.g., iisnode, web.config, named pipes, Win32 error codes, Kudu CMD/PowerShell). There are no Linux equivalents or cross-platform guidance, and Linux-specific scenarios or tools are not mentioned or linked.

Recommendations:

Add a parallel section or page for Node.js on Azure App Service for Linux, including best practices and troubleshooting steps relevant to Linux environments.
Provide Linux-specific configuration and troubleshooting examples (e.g., using PM2, NGINX/Apache, Linux file paths, environment variables).
Include examples of accessing logs, debugging, and profiling on Linux-based App Service (e.g., using SSH, Bash, Linux log directories).
Reference Linux tools and patterns (such as systemd, journalctl, Bash scripts) alongside or before Windows tools where appropriate.
Clearly indicate at the top of the page that the content is Windows-specific, and provide links to Linux documentation for parity.
Avoid assuming the use of Windows-only features (like web.config, named pipes, Win32 error codes) without offering Linux alternatives or explanations.

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 project root location and only providing a Windows example for where to place the configuration file. Linux is mentioned only in a note, with no Linux-specific example or illustration. The documentation also refers to Windows paths and conventions before Linux, and does not provide equivalent Linux command-line or file path examples.

Recommendations:

Provide both Windows and Linux file path examples when describing where to place the configuration file (e.g., C:\home\site\wwwroot\auth.json for Windows, /home/site/wwwroot/auth.json for Linux).
Instruct users on how to deploy or locate the configuration file on both Windows and Linux App Service environments.
When referencing platform-specific behaviors (such as configFilePath requirements), present Linux and Windows information in parallel, rather than Windows first.
Include Linux-specific notes or examples wherever Windows-specific tools, paths, or conventions are mentioned.
Consider adding a table or section summarizing differences between Windows and Linux App Service environments for this feature.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a subtle Windows bias by referencing Windows-specific tools (Azure Storage Explorer) and providing instructions that are either Windows-centric or lack Linux alternatives. The only tool-specific example for generating a SAS is linked with a Windows tab, and there is no mention of Linux-native tools or cross-platform alternatives for file upload or SAS generation. All command-line examples use Azure CLI, which is cross-platform, but the supporting tooling and workflow references are Windows-first.

Recommendations:

Include explicit instructions or links for performing key tasks (such as uploading files and generating SAS tokens) using Linux-native tools (e.g., Azure CLI, azcopy, or REST API) alongside Storage Explorer.
When referencing GUI tools like Azure Storage Explorer, clarify their cross-platform availability and provide screenshots or instructions for both Windows and Linux (and macOS) where applicable.
Avoid linking to documentation with Windows-specific tabs by default; ensure parity by linking to generic or cross-platform instructions.
Mention and provide examples for using azcopy or Azure CLI for file uploads and SAS generation, which are fully cross-platform.
Audit all steps to ensure that Linux users are not left to infer or research alternative workflows.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ powershell_heavy

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 (CMD, PowerShell, Kudu), with no mention of Linux equivalents or how to perform similar tasks on Linux-based App Service plans. There are no Linux shell or cross-platform examples, and the documentation assumes the use of Visual Studio and Windows-centric workflows.

Recommendations:

Add parallel instructions and examples for Linux-based App Service plans, including how to check installed .NET runtimes and access diagnostic tools.
Include Linux shell (bash) commands and file paths where appropriate, especially for runtime version discovery and environment variable access.
Mention and demonstrate cross-platform deployment tools (such as Azure CLI, GitHub Actions, or VS Code) alongside Visual Studio.
Clarify when instructions or features are Windows-only, and provide links or references to Linux-specific documentation where available.
Balance the order of presentation so that Linux and Windows approaches are presented together or Linux is not consistently omitted or placed after Windows.

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 prescriptive, with step-by-step PowerShell and batch script examples. Windows-specific tools and environment variables (e.g., PowerShell, %HOME%, %LOCAL_EXPANDED%) are emphasized, and the Windows workflow is described in greater detail than the Linux equivalent. Linux instructions are present and functional, but the Windows approach is more thoroughly documented and uses Windows-native scripting and tools.

Recommendations:

Provide equally detailed Linux examples, including a full sample startup script (e.g., Bash) for automating Tomcat configuration changes, similar to the PowerShell script for Windows.
Where Windows-specific tools (PowerShell, batch files) are used, offer direct Linux equivalents (e.g., Bash scripts) and explain their usage.
Ensure that Linux instructions are as step-by-step and prescriptive as the Windows ones, including troubleshooting tips and environment variable usage.
Highlight cross-platform approaches (such as using Azure CLI or environment variables) before platform-specific solutions.
Where possible, use neutral, platform-agnostic terminology and structure (e.g., refer to 'startup scripts' generically, then provide both Bash and PowerShell examples).

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation generally provides parity between Linux and Windows, but there are several areas where Windows is prioritized or Linux is underrepresented. In some sections, Windows instructions or tools (such as Kudu, FTPS, and web.config) are mentioned specifically or with more detail, and Windows-specific patterns (like using Kudu's Process Explorer) are described before or instead of Linux equivalents. Some advanced troubleshooting and configuration steps are more detailed for Windows, and certain features (like Tomcat baseline configuration) are explicitly marked as Linux-only, with no equivalent Windows guidance. There are also references to Windows-specific tools and conventions (e.g., C:\ paths, web.config, Kudu), and in some cases, Linux command-line or troubleshooting examples are less comprehensive.

Recommendations:

Ensure that all examples and instructions are provided for both Linux and Windows, with equal detail and prominence.
When mentioning tools like Kudu or FTPS, clarify their availability and usage on both platforms, or provide Linux-native alternatives where appropriate.
Avoid Windows-first ordering in sections that apply to both platforms; alternate or parallelize instructions for Linux and Windows.
Where features are Linux-only (such as Tomcat baseline configuration), provide a clear explanation and, if possible, suggest equivalent approaches or workarounds for Windows users.
Expand Linux troubleshooting and configuration examples to match the depth provided for Windows, including advanced scenarios.
Review all CLI and scripting examples to ensure both Bash (Linux) and PowerShell (Windows) variants are included where relevant.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows-first bias by referencing Windows file paths (e.g., D:\home\site\wwwroot) before Linux equivalents, using Windows directory separators in examples, and omitting explicit Linux command-line or file path examples. The instructions and troubleshooting sections focus on Windows conventions, and there are no Linux-specific deployment or troubleshooting examples provided.

Recommendations:

Provide Linux file path examples (e.g., /home/site/wwwroot) alongside Windows paths in all relevant sections.
Include Linux command-line examples (such as Bash or shell commands) where appropriate, especially for manual file operations.
Use platform-agnostic language and directory separators (e.g., <root>/site/wwwroot) or clearly indicate both Windows and Linux variants.
Add troubleshooting notes specific to Linux environments, such as permissions or case sensitivity issues.
Ensure that any references to tools or workflows (such as FTP paths or directory creation) are explained for both Windows and Linux users.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias, particularly in the .NET/ASP.NET sections, where Windows tools (Visual Studio, Azure PowerShell) are listed before Linux-friendly or cross-platform options. PowerShell is specifically called out as a deployment tool, but there is no mention of Bash or Linux shell equivalents. In the Python section, 'windows' is present in the tab parameters for CLI and VS Code instructions, and Linux-specific instructions are not clearly prioritized or separated. The 'Next step' call-to-action is for deploying an ASP.NET app, which is most commonly associated with Windows. In contrast, Linux-first or cross-platform approaches are less visible or are listed after Windows-centric tools. Some stacks (PHP, Node.js) do better, but the overall structure and example ordering favor Windows.

Recommendations:

For each stack, ensure that Linux and cross-platform tools (e.g., Azure CLI, Bash, VS Code) are listed before or alongside Windows-specific tools like Visual Studio and PowerShell.
Where PowerShell is mentioned, also provide equivalent Bash or Azure CLI examples, and make these visible and easy to find.
In the Python section, clarify and separate Linux and Windows instructions, and avoid defaulting to 'windows' in tab parameters for CLI examples.
Balance the 'Next step' call-to-action by either making it stack-neutral or providing Linux-friendly options (e.g., 'Deploy a Node.js app on Linux').
Audit all quickstart and deployment links to ensure Linux parity and that Linux users are not required to adapt Windows-centric instructions.
Consider adding a table or section summarizing tool parity for Windows and Linux users for each stack.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation demonstrates a Windows bias by prioritizing Visual Studio and GUI-based instructions (e.g., right-clicking folders, using NuGet package manager) without providing equivalent Linux or cross-platform command-line alternatives. There are no explicit Linux or macOS examples for project setup, package installation, or deployment, and the documentation assumes the use of Windows-centric tools and workflows.

Recommendations:

Provide explicit instructions for Linux/macOS users, such as using the dotnet CLI for project/file creation (e.g., 'dotnet new razor', 'dotnet add package').
Include examples for installing and managing NuGet packages via the command line (dotnet CLI), not just through Visual Studio.
Replace or supplement GUI-based steps (like 'right-click to add a file') with equivalent CLI commands (e.g., 'touch OpenAI.razor' or 'echo' commands).
Clarify that all code and deployment steps are cross-platform, and specify any OS-specific differences where relevant.
Add a section or callouts for deploying and testing the app locally on Linux/macOS, including environment variable management and troubleshooting tips.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ windows_first

Summary:

The documentation page demonstrates a strong Windows bias by providing only PowerShell examples for per-app scaling, with no equivalent examples for Linux-native tools (such as Azure CLI or Bash). The use of PowerShell cmdlets is presented as the primary method for configuration, and there is no mention of cross-platform or Linux-first approaches. This may hinder accessibility for Linux users or those working in cross-platform environments.

Recommendations:

Add equivalent Azure CLI examples for all PowerShell commands shown, using Bash syntax.
Explicitly mention that PowerShell examples are for Windows and provide guidance for Linux/macOS users.
Where possible, use cross-platform tools (e.g., Azure CLI) as the primary example, or present them before PowerShell.
Include notes or links to documentation for configuring per-app scaling using REST API or SDKs, which are platform-agnostic.
Review and update documentation metadata (such as devx-track-azurepowershell) to ensure cross-platform parity is prioritized.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ 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 Azure CLI, and in some cases, is presented before or alongside it without clarifying cross-platform applicability. There are no explicit Linux shell or Bash-native examples (other than the nslookup and curl commands), and the PowerShell examples may not be directly usable on Linux systems without additional setup. Outbound IPv6 support is noted as being available only for Windows apps, but this is a platform limitation rather than documentation bias.

Recommendations:

Clearly indicate that Azure CLI commands are cross-platform and preferred for Linux/macOS users, while PowerShell is primarily for Windows (unless using PowerShell Core).
Present Azure CLI examples before PowerShell examples to avoid the perception of Windows-first bias.
Where PowerShell is shown, clarify its platform compatibility (e.g., note if it works with PowerShell Core on Linux).
Add explicit Bash or shell-native examples where possible, especially for common tasks like parsing JSON output from Azure CLI.
In sections about platform-specific features (like outbound IPv6), clarify that limitations are due to service capabilities, not documentation focus.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows bias by referencing Windows-specific paths (e.g., D:\home), using Windows-centric terminology and folder structures, and omitting Linux-specific examples or equivalents. Tools and instructions (such as Kudu/SCM) are described in a way that assumes a Windows environment, and there is no mention of how to perform similar operations on Linux-based App Service plans. Linux and container scenarios are only mentioned in passing, mainly to state that the feature is not supported, without providing guidance or alternatives for Linux users.

Recommendations:

Provide equivalent Linux path examples (e.g., /home/site) alongside Windows paths.
Include instructions and screenshots for enabling and managing local cache on Linux-based App Service plans, or explicitly clarify feature parity and alternatives.
Mention Linux-compatible tools or commands (such as Bash, Azure CLI on Linux) where relevant.
Clarify differences in folder structure and environment variables for Linux App Service environments.
If the feature is unsupported on Linux, offer guidance or links to alternative caching strategies or features for Linux/container users.

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 limitations specifically for Windows Containers, including subnet sizing and networking units, while not offering equivalent details for Linux containers. The only explicit mention of Linux is in the context of continuous deployment network dependencies, which is brief and lacks parity with the Windows-focused section. There are no Linux-specific examples, tools, or troubleshooting steps, and the documentation does not address Linux container-specific networking considerations.

Recommendations:

Add a parallel section detailing subnet sizing, networking unit calculations, and limitations for Linux containers, similar to the 'Windows Containers specific limits' section.
Include Linux-specific examples or troubleshooting steps where relevant, especially in areas like scaling, networking, and deployment.
Ensure that any Windows-specific guidance is matched with Linux equivalents, or explicitly state when a limitation or feature is Windows-only.
Provide links to Linux container documentation or best practices for App Service VNet integration.
Review the order of presentation to avoid always listing Windows scenarios first; consider a more balanced or side-by-side approach.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation exhibits a Windows-first bias in several ways. Windows-specific paths and tools (such as D:\home, Web Deploy/MSDeploy, and references to IIS, w3wp.exe, and applicationHost.config) are mentioned frequently and often before or instead of their Linux equivalents. Many environment variable descriptions and examples default to Windows conventions, with Linux details sometimes appearing as an afterthought or not at all. There are also numerous references to Windows-specific behaviors, tools, and error messages, while Linux-specific guidance is less detailed or omitted.

Recommendations:

Ensure that all environment variable descriptions and examples include both Windows and Linux paths, formats, and behaviors where applicable.
When mentioning tools or deployment methods (e.g., Web Deploy/MSDeploy), provide equivalent Linux-native alternatives or clarify their applicability.
Avoid defaulting to Windows paths (e.g., D:\home) in examples; instead, show both Windows and Linux paths side by side.
Balance the level of detail for Windows and Linux throughout the documentation, especially in troubleshooting and configuration sections.
Where Windows-specific settings or behaviors are described, explicitly state if and how they differ on Linux, and provide Linux-specific guidance.
Review and expand Linux-specific sections (such as Oryx build automation) to match the depth and clarity of the Windows/Kudu sections.
Audit for references to Windows-only tools, error messages, or file structures, and add Linux equivalents or clarifications as needed.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation demonstrates a Windows-first bias by providing more detailed instructions and features for Windows App Service apps, such as web server logging, detailed error messages, and failed request tracing, which are either unavailable or not documented for Linux apps. Examples and tool mentions (like Log Parser and W3C log formats) are Windows-centric, and Linux-specific guidance is minimal or missing for several logging features.

Recommendations:

Provide equivalent, step-by-step instructions for enabling and accessing web server logging, detailed error messages, and failed request tracing for Linux-based App Service apps, or clearly state if these features are unavailable.
Include Linux-specific examples and file paths alongside Windows examples, especially in sections describing log file locations and structures.
Mention and recommend cross-platform or Linux-native tools (e.g., jq, grep, less, or open-source log viewers) for log analysis, not just Windows tools like Log Parser.
Clarify any feature gaps between Windows and Linux App Service plans up front, and link to Linux-specific troubleshooting/logging documentation where available.
Ensure parity in code samples for logging (e.g., provide Python, Node.js, or Java examples, not just .NET/ASP.NET).

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by focusing on Windows-specific tools (IIS, Procdump, PowerShell), referencing Windows terminology (web.config, .NET Profiler for Windows), and omitting equivalent Linux guidance or examples. Linux-specific diagnostic methods, tools, and code samples are not provided, and Windows approaches are often mentioned first or exclusively.

Recommendations:

Provide Linux-specific instructions and examples alongside Windows ones, especially for diagnostics, logging, and profiling.
Mention Linux equivalents for tools such as IIS diagnostics (e.g., Nginx/Apache logs), Procdump (e.g., gcore, dotnet-dump), and PowerShell (e.g., Bash/CLI commands).
Clarify which features or instructions are Windows-only and offer alternative steps for Linux-based App Service environments.
Include code/configuration samples for both Windows (.NET/web.config) and Linux (Node.js, Python, etc.) stacks.
Update references and links to include Linux-focused documentation where available.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ windows_first

Summary:

The documentation assumes a development environment based on GitHub Codespaces and Azure App Service, both of which are cross-platform but the tutorial is heavily oriented toward .NET and Azure tooling. There are no explicit Linux or macOS terminal instructions, and the workflow references tools and deployment patterns (such as Azure Developer CLI and App Service) that are more familiar to Windows/.NET developers. There are no mentions of Linux-specific environments, shell commands, or alternative editors/IDEs. All code and examples are .NET/C#-centric, with no parity for other platforms or languages.

Recommendations:

Add explicit instructions or notes for running the tutorial on Linux and macOS, including shell command equivalents and environment setup.
Mention that .NET Core and Azure CLI are cross-platform, and provide bash/zsh shell command examples alongside dotnet CLI commands.
Include a section or callout for deploying to Azure App Service from Linux/macOS terminals, or using VS Code on Linux.
Reference alternative editors (such as VS Code) and clarify that the tutorial is not limited to Windows.
If possible, provide parity examples for other common web stacks (e.g., Node.js/Express, Python/Flask) to broaden accessibility.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

Summary:

The documentation demonstrates a moderate Windows bias, primarily through the use of PowerShell commands and references to Windows-centric tools (e.g., AzPowerShell, PowerShell@2 tasks) in CI/CD examples. While the workflows are shown running on Ubuntu runners, the scripting and authentication steps often default to PowerShell or Windows-specific patterns. There is little to no mention of Linux shell equivalents or alternative Linux-native tooling, and PowerShell-based steps are presented without parallel bash/sh alternatives. Additionally, Windows/PowerShell terminology is used before or instead of Linux equivalents, especially in Azure Pipelines sections.

Recommendations:

Provide equivalent bash/sh script examples alongside PowerShell commands for installing dependencies, running tests, and authentication steps.
In Azure Pipelines, offer both PowerShell and bash scriptType examples, or default to bash where possible for cross-platform compatibility.
Clarify that AzPowerShell and PowerShell@2 tasks are not required if using Linux runners, and provide guidance for using AzureCLI or bash scripts.
Explicitly mention Linux-native tools and patterns where applicable (e.g., using export for environment variables, using bash for scripting).
Ensure that Linux and macOS users are equally represented in code snippets and workflow steps, not just by the runner OS but also by the scripting language and tools.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias by prioritizing Windows-centric tools and workflows, such as Visual Studio Code and PowerShell/.NET examples, and by omitting explicit Linux/macOS instructions or screenshots. The CLI and environment setup sections assume familiarity with Windows developer tooling and do not provide parity for Linux users, especially regarding environment variable management, editor integration, and .NET/NUnit usage.

Recommendations:

Provide explicit Linux/macOS instructions and screenshots alongside Windows/Visual Studio Code examples, especially for environment setup and running tests.
Include alternative editor workflows (e.g., JetBrains Rider, Vim, or command-line only) for users not on Windows or not using Visual Studio Code.
For .NET/NUnit sections, clarify cross-platform compatibility and provide Linux/macOS-specific commands or troubleshooting tips.
When referencing environment variables, show both Windows (set/PowerShell) and Linux/macOS (export) syntax.
Avoid assuming Visual Studio Code as the default editor; mention it as one option among several.
Add a section or callout explicitly stating that all steps are cross-platform unless otherwise noted, and link to Playwright's official cross-platform documentation.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation demonstrates a moderate Windows bias. Windows-specific concepts (such as registry keys, Windows services, and file paths) are described in detail, often with examples or tables, while Linux equivalents (such as daemons or configuration files) are mentioned but not explored with the same depth. In several sections, Windows tools and patterns (e.g., registry, Windows services, c:\ paths) are presented first or exclusively, and Linux-specific examples are sparse or absent. The alerting/query examples and registry monitoring are heavily Windows-centric, and there is little explanation or tabular detail for Linux-specific monitoring (e.g., no table of common Linux daemon paths or config files). Some command-line examples are presented for both platforms, but the overall narrative and examples lean toward Windows.

Recommendations:

Add equivalent Linux-focused sections, such as a table of commonly monitored Linux configuration files or directories (e.g., /etc/passwd, /etc/ssh/sshd_config) and common daemons.
Provide Linux-specific examples for alerting and queries, such as tracking changes to /etc/hosts, /etc/shadow, or systemd service states.
Balance the order of presentation: when listing features, alternate or parallelize Windows and Linux examples (e.g., 'Windows registry or Linux configuration files').
Expand the explanation of Linux daemon monitoring, including what is tracked and how, similar to the Windows registry section.
Where screenshots or UI references are given, ensure Linux scenarios are depicted as well.
Clarify any platform-specific limitations or differences in parity, and provide migration or workaround guidance for Linux users.

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 Windows-specific tools (setx, PowerShell) with detailed usage. While Linux/macOS commands are present, Windows instructions are consistently listed first, and PowerShell is given its own example. No Linux-specific tools or patterns are highlighted.

Recommendations:

Present Linux/macOS and Windows instructions in parallel tabs or side-by-side, rather than listing Windows first.
Avoid giving Windows command prompt and PowerShell separate, prioritized sections unless Linux shells are given equal prominence.
Consider leading with cross-platform shell commands (e.g., bash) or providing a neutral default, with OS-specific instructions in expandable sections.
If mentioning Windows tools like setx, also mention Linux equivalents (e.g., export, or how to persist environment variables in .bashrc/.zshrc) and provide links to relevant documentation.
Ensure that Linux/macOS users are not treated as an afterthought by giving their instructions equal detail and placement.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation demonstrates a mild Windows bias. Command-line examples are consistently presented in 'dos' code blocks, which are typically associated with Windows CMD or PowerShell, even though the redis-benchmark tool is cross-platform and most commonly used from Linux shells. There are no explicit Linux shell examples for redis-benchmark, and the code block syntax may confuse Linux users. The documentation refers to 'client VMs' generically, but does not provide Linux-specific installation or usage guidance, nor does it mention Linux tools or patterns. However, the memtier-benchmark section does use 'bash' code blocks, which is more Linux-friendly.

Recommendations:

Provide redis-benchmark command examples in both Windows (CMD/PowerShell) and Linux (bash/sh) syntax, using appropriate code block annotations.
Include explicit instructions or links for installing redis-benchmark on Linux distributions, not just a generic link to Redis documentation.
Clarify that redis-benchmark is available and commonly used on Linux, and provide parity in troubleshooting or usage notes for both platforms.
Where 'dos' code blocks are used, add a parallel 'bash' tab or section for Linux users.
Mention Linux as a first-class platform for running Redis benchmarks, and avoid defaulting to Windows-centric terminology or code block syntax.

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 it introduces PowerShell examples immediately after CLI, and does not mention or provide any Linux shell (bash) or scripting examples. PowerShell is a Windows-centric tool, and its inclusion without equivalent Linux-native scripting (e.g., bash, shell scripts) may disadvantage Linux users. There is also no mention of Linux-specific considerations or tools, and the CLI examples do not explicitly show usage in a Linux environment.

Recommendations:

Add explicit bash/shell script examples alongside Azure CLI commands to demonstrate usage in Linux environments.
Clarify that Azure CLI commands are cross-platform and can be run in Linux, macOS, and Windows, possibly providing terminal screenshots or notes for Linux users.
Balance the order of examples: alternate between CLI and PowerShell, or group by platform (Windows vs. Linux/macOS), rather than presenting PowerShell immediately after CLI.
Mention any Linux-specific prerequisites or considerations, such as package installation or environment setup for Azure CLI on Linux.
If possible, provide automation examples using common Linux tools (e.g., curl, jq) for REST API calls, in addition to Azure CLI.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation demonstrates a mild Windows bias. Windows-specific tools and patterns (such as WSL and Windows Terminal) are mentioned prominently, and Azure PowerShell is listed alongside Azure CLI as a primary method for retrieving keys. The installation instructions for Windows focus on using WSL rather than native Windows binaries or alternatives, and references to Windows tooling appear before or alongside Linux equivalents. However, Linux installation and usage are well-covered, and most command examples are cross-platform.

Recommendations:

Provide explicit instructions or references for native redis-cli binaries for Windows, if available, rather than only recommending WSL.
List Azure CLI as the primary method for retrieving keys, with PowerShell as an alternative, to reflect cross-platform parity.
When mentioning Windows-specific tools (like Windows Terminal), also mention popular Linux/macOS terminal options for balance.
Ensure that all examples and instructions are clearly marked as cross-platform where applicable, and avoid implying that Windows is the default or preferred environment.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation exhibits a mild Windows bias. In several places, Windows-specific tools or settings are mentioned before their Linux equivalents (e.g., ReadyToRun runtime identifiers, deployment requirements, and preview .NET version configuration). Some instructions and examples are Windows-centric or list Windows first, and there are references to Visual Studio (a Windows-first tool) without always providing parity for Linux/VS Code. In a few cases, Linux-specific instructions are less detailed or missing, and Azure PowerShell (primarily used on Windows) is listed as a deployment option without equivalent emphasis on Bash or Linux-native scripting.

Recommendations:

Ensure that all CLI and deployment instructions are provided for both Windows and Linux, with equal detail and prominence.
When listing tools or options (e.g., Visual Studio, PowerShell), always include Linux-friendly alternatives (e.g., VS Code, Bash scripts, Azure CLI) and avoid listing Windows tools first by default.
For configuration tables or code snippets (e.g., ReadyToRun, deployment requirements), present Linux and Windows options side-by-side or in parallel tabs, not with Windows first.
When referencing PowerShell, also provide Bash/Azure CLI equivalents and highlight cross-platform approaches.
Review all sections for parity in debugging, deployment, and project setup instructions, ensuring Linux users have clear, direct guidance.
Explicitly mention if a feature or tool is Windows-only, and suggest Linux alternatives where possible.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation demonstrates a Windows bias by exclusively referencing Visual Studio Code and Azurite usage patterns that are most familiar to Windows users. Instructions for starting Azurite and running the function app use the Visual Studio Code command palette (F1) and function keys (F5), which are more commonly associated with Windows environments. There are no explicit instructions or terminal commands for starting Azurite or running/debugging the function app from a Linux or macOS terminal. Additionally, there is no mention of Linux-specific tools or alternative workflows, and the use of 'local.settings.json' and 'UseDevelopmentStorage=true' assumes a development pattern typical of Windows setups.

Recommendations:

Add explicit instructions for starting Azurite and running/debugging the function app from the terminal (e.g., using `azurite` and `func start` commands), which are platform-agnostic and especially relevant for Linux/macOS users.
Include notes or callouts for Linux/macOS users regarding any differences in keyboard shortcuts or command palette access in Visual Studio Code.
Mention and provide examples for using actual Azure Storage accounts as an alternative to Azurite, and clarify any platform-specific considerations.
Ensure all steps that reference file paths, commands, or tools are verified to work on Linux/macOS and provide alternative instructions if necessary.
Consider adding a prerequisites section that explicitly lists supported platforms and any platform-specific setup steps.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation demonstrates a moderate Windows bias. Windows-based examples and tools are often presented first, especially for .NET/C# and PowerShell. The default agent image for C# and PowerShell is 'windows-latest', and PowerShell is only shown with Windows agents. While Linux (ubuntu-latest) is used for JavaScript and Python, and Linux deployment is covered, the structure and ordering of examples generally prioritize Windows. There is also a lack of parity in PowerShell examples for Linux, and the documentation assumes Windows as the default for several tasks.

Recommendations:

For C#/.NET examples, provide both 'windows-latest' and 'ubuntu-latest' YAML samples, or clarify cross-platform compatibility.
For PowerShell, clarify if Linux agents are supported and provide examples for Linux if available (e.g., using pwsh on Ubuntu agents).
When listing deployment options, present Windows and Linux options side-by-side or in parallel tabs, rather than defaulting to Windows.
Explicitly mention when a feature or task is Windows-only or Linux-only, and provide guidance for the other OS where possible.
In introductory and summary sections, avoid language that assumes Windows as the default; instead, state that both Windows and Linux are supported and highlight any differences up front.

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 or mentions of Linux-based .NET web apps, nor are Linux tools, commands, or assessment patterns referenced. The linked resources and terminology (e.g., ASP.NET, App Service) reinforce a Windows-centric perspective.

Recommendations:

Include explicit guidance or examples for assessing .NET web apps running on Linux (e.g., ASP.NET Core on Linux).
Mention and link to Linux-compatible tools or command-line instructions for assessment.
Clarify whether the assessment process and recommendations apply equally to Linux-hosted .NET apps, or note any differences.
Add references to Linux migration scenarios and best practices where relevant.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation presents Windows container SSH access first and describes it as requiring no modifications, while Linux custom containers are described as needing extra configuration. The detailed SSH access instructions and examples (CLI commands, SSH session walkthrough) are provided only for Linux containers, with no equivalent CLI or PowerShell instructions for Windows containers. This creates a 'windows_first' bias in structure, but a 'missing_linux_example' bias in the Windows section, as it lacks parity in example depth.

Recommendations:

Provide equivalent, detailed SSH access instructions for Windows containers, including any available CLI or PowerShell commands, or explicitly state if such access is not possible.
Balance the order of presentation by either combining the Linux and Windows instructions or alternating which platform is presented first.
If Windows containers do not support CLI-based SSH access, clearly explain the limitation and suggest any available alternatives.
Ensure both platforms have comparable example depth and clarity, including troubleshooting tips and session output where possible.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page shows a subtle Windows bias by referencing Windows first in the sample app quickstart link (with 'tabs=flask,windows,azure-cli,...'), and does not provide any explicit Linux-specific instructions or examples for environment setup, deployment, or tooling. While the core instructions are cross-platform (Python, Flask, Azure), there is a lack of parity in highlighting Linux workflows or mentioning Linux-specific considerations.

Recommendations:

Ensure that quickstart and reference links include Linux as a first-class option, or provide parallel Linux and Windows tabs/examples.
Explicitly mention that all instructions (such as environment variable setup, running pip, etc.) work on both Windows and Linux, or call out any differences.
Provide Linux-specific deployment guidance or troubleshooting tips, especially for common issues (e.g., file permissions, case sensitivity, using bash/zsh shells).
If referencing the Azure portal or CLI, clarify that these steps are OS-agnostic, or provide command-line examples for both Windows (PowerShell/cmd) and Linux (bash).
Consider adding a section or callout for Linux users to ensure they feel equally supported.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation demonstrates environment-based configuration using ASP.NET Core and Azure App Configuration, but it assumes the use of Windows-centric tooling and patterns. It references modifying 'launchSettings.json' (a Visual Studio/Windows convention) and does not provide equivalent instructions or examples for Linux or cross-platform development environments. There are no Linux shell or cross-platform CLI examples for setting environment variables or running the application in different environments.

Recommendations:

Include instructions for setting environment variables on Linux/macOS (e.g., using 'export ASPNETCORE_ENVIRONMENT=Production' in the shell) alongside the 'launchSettings.json' method.
Mention that 'launchSettings.json' is primarily used in Visual Studio and may not be present or used in all development environments, especially on Linux.
Provide examples of running the application from the command line with environment variables set for both Windows (using 'set' or 'setx') and Linux/macOS (using 'export').
Clarify that the instructions apply to cross-platform .NET Core development and highlight any platform-specific steps.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

Summary:

The documentation provides both Azure PowerShell and Azure CLI examples for scaling Azure Cache for Redis, but PowerShell examples are consistently presented before Azure CLI. This ordering, along with the prominence of PowerShell (a Windows-centric tool), may suggest a Windows-first bias. However, the presence of Azure CLI examples ensures Linux users are not excluded. There are no examples or instructions that are strictly Windows-only, and no exclusive mention of Windows tools or patterns. No Linux-specific tools or shell examples (e.g., Bash scripts) are provided.

Recommendations:

Alternate the order of PowerShell and Azure CLI examples, or present Azure CLI examples first to better reflect cross-platform parity.
Explicitly mention that Azure CLI commands work on Linux, macOS, and Windows to reinforce cross-platform support.
Consider adding Bash shell script examples or notes for Linux users where appropriate.
Where possible, provide links to documentation or quickstarts for both Windows and Linux environments.
Avoid language that implies PowerShell is the default or preferred automation tool.

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation page lists .NET and related Microsoft technologies (including .NET Standard, ASP.NET Core, Azure Functions, .NET Framework) first in both the provider library table and the feature matrix, before Java, Python, JavaScript, and Go. There are no explicit Windows-only tools or PowerShell examples, but the ordering and emphasis on .NET ecosystems (which are historically Windows-centric) may suggest a bias toward Windows/Microsoft platforms.

Recommendations:

Reorder the provider library table and feature matrix to avoid always listing .NET/Microsoft-first; consider alphabetical or usage-based ordering.
Explicitly mention cross-platform compatibility for .NET providers, clarifying that they work on Linux and macOS as well as Windows.
Add a brief section or note highlighting parity and support for Linux and non-Windows environments.
If possible, provide Linux-specific usage notes or examples, especially for scenarios where platform differences may arise.
Ensure that future documentation and samples are balanced in coverage between Windows and Linux environments.

Create pull request

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