Scan Details - Linux-first Docs for Azure

1133

Pages Scanned

47

Pages Flagged

1133

Changed Pages

4.1%

% Pages Flagged

Scan Information

Started At: 2025-09-07 00:00:40

Finished At: 2025-09-07 00:24:15

Status: completed

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

Current Phase: discovery

Problematic Pages

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows bias by referencing Windows-specific tools and patterns (such as web.config and iisnode) without providing equivalent Linux guidance or examples. Linux-specific configuration methods are not mentioned in sections where Windows approaches are described, and Windows tools are referenced first or exclusively.

Recommendations:

For features like auto-healing, provide Linux-specific configuration instructions (e.g., using application settings or startup scripts) alongside or before mentioning web.config.
When referencing iisnode or web.config for Node.js apps, include guidance for Linux-based App Service plans, such as using PM2, environment variables, or other process managers.
Ensure that all examples and troubleshooting steps are provided for both Windows and Linux environments, or clearly indicate when a feature is platform-specific.
Where possible, use cross-platform terminology and tools, or provide parallel instructions for both operating systems.
Add explicit Linux configuration examples for common scenarios (e.g., memory/CPU troubleshooting, process management) to achieve parity.

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 Windows-centric technologies. There are no references to Linux-based hosting, such as Kestrel or Apache/Nginx, nor are there examples or guidance for discovering .NET apps on Linux servers. All discovery capabilities and tooling mentioned (Azure Migrate appliance, IIS) are Windows-specific, with no Linux equivalents or parity.

Recommendations:

Include explicit guidance or notes about discovering .NET apps hosted on Linux servers, such as those running Kestrel, Apache, or Nginx.
Provide examples or documentation links for Linux-based discovery scenarios, if supported.
Clarify whether the Azure Migrate appliance supports Linux environments, and if not, state this limitation clearly.
If Linux discovery is not supported, suggest alternative approaches or tools for Linux users.
Ensure future documentation covers both Windows and Linux hosting scenarios for .NET apps to improve cross-platform parity.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a strong Windows bias. All migration tools and examples focus exclusively on migrating ASP.NET apps from Windows/IIS environments, with repeated references to PowerShell scripts and Windows-specific tools. There is no mention of Linux-based .NET hosting environments (e.g., Apache, Nginx), nor are there any Linux command-line or migration examples. The documentation assumes the source environment is always Windows/IIS, omitting guidance for users migrating from Linux servers.

Recommendations:

Add examples and guidance for migrating .NET web apps hosted on Linux servers (e.g., Apache, Nginx, Kestrel) to Azure App Service.
Include Linux shell (bash) script equivalents for PowerShell-based migration steps.
Mention and link to any available tools or manual processes for assessing and migrating .NET apps from Linux environments.
Clarify in tool descriptions whether they support Linux-based migrations, and if not, provide alternative recommendations.
Present migration scenarios for both Windows and Linux environments, ensuring parity in documentation structure and detail.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation demonstrates a Windows bias by providing PowerShell scripts as the only automation example for identifying Traffic Manager endpoints, without offering Bash, Azure CLI, or cross-platform alternatives. References to PowerShell are made without mention of Linux/macOS compatibility or equivalent Bash/CLI scripts. This may disadvantage users on non-Windows platforms, as the guidance assumes access to and familiarity with PowerShell and Windows tooling.

Recommendations:

Provide equivalent Bash or Azure CLI scripts for all PowerShell examples, especially for resource discovery and automation tasks.
When referencing scripts or automation, explicitly state whether they are cross-platform or provide alternatives for Linux/macOS users.
List Azure CLI and REST API commands before or alongside PowerShell commands to avoid a 'Windows-first' impression.
Clarify in the documentation that PowerShell Core is available cross-platform, or provide instructions for running scripts on Linux/macOS if no alternative is available.
Ensure that all referenced GitHub scripts or tools have clear cross-platform compatibility notes or alternatives.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a moderate Windows bias. Windows instructions, tools, and troubleshooting steps are often presented first or exclusively, with more detail and screenshots for Windows GUI tools. PowerShell commands are used for network testing without equivalent Linux examples. The Windows GUI for Hybrid Connection Manager is featured, while Linux users are limited to CLI with less visual guidance. Some troubleshooting steps and tool references (e.g., Test-NetConnection) are Windows-specific, and Linux alternatives are not always provided.

Recommendations:

Provide Linux equivalents for all PowerShell commands (e.g., suggest 'nc', 'telnet', or 'curl' for network testing).
When referencing tools like 'Test-NetConnection', include the Linux alternative alongside the Windows example.
Balance the order of presentation: alternate which OS is presented first, or present both together where possible.
Offer more visual aids or step-by-step CLI examples for Linux users, compensating for the lack of GUI.
Explicitly mention any feature parity or limitations between Windows and Linux at the start of each relevant section.
Where GUI-only features exist for Windows, suggest or develop CLI/alternative workflows for Linux.
In troubleshooting, include Linux-native commands for DNS lookup (e.g., 'dig', 'host', or 'nslookup') and endpoint testing.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias by referencing Windows-style paths (e.g., D:\home), describing folder structures and behaviors using Windows conventions, and mentioning Windows-specific tools and deployment patterns (such as Kudu/SCM and Azure Web Apps Disk Usage) without providing equivalent Linux examples or clarifying differences for Linux-based App Service plans. There are no Linux command-line examples or explicit guidance for Linux users, and Linux container support is only mentioned in a note about lack of support, not in positive examples.

Recommendations:

Include parallel Linux examples and path conventions (e.g., /home/site/wwwroot) alongside Windows paths.
Clarify differences in local cache behavior for Linux-based App Service plans and provide explicit guidance for Linux users.
Mention and provide examples of Linux-compatible tools or commands for checking disk usage and environment variables.
Where features are unsupported on Linux, offer alternative recommendations or workarounds for Linux users.
Ensure that all code snippets, folder references, and troubleshooting steps are presented for both Windows and Linux environments.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation generally provides both Linux and Windows instructions, but there are several areas where Windows is prioritized or receives more detailed coverage. Windows-specific tools and patterns (such as Kudu, Advanced Tools, and FTPS) are mentioned prominently, sometimes before Linux equivalents. Some sections (e.g., Java Flight Recorder, logging, and process management) provide more step-by-step detail for Windows, including GUI navigation, while Linux instructions are more command-line focused or less detailed. There are also references to Windows-specific behaviors (like web.config) and tools without always providing Linux alternatives or parity in explanation.

Recommendations:

Ensure that Linux and Windows instructions are presented with equal prominence and detail, ideally side-by-side or with Linux-first ordering where appropriate.
Where Windows-specific tools (e.g., Kudu, FTPS, Advanced Tools) are referenced, provide equivalent Linux-native approaches or clarify if not applicable.
Expand Linux examples to match the step-by-step detail given for Windows, especially for tasks like process management, log retrieval, and profiler usage.
Avoid referencing Windows-specific configuration files (like web.config) without noting their irrelevance on Linux, and provide Linux-specific configuration guidance where applicable.
Review all sections for parity in troubleshooting, deployment, and configuration guidance, ensuring Linux users are not left with less actionable information.
Where possible, use cross-platform CLI tools (e.g., Azure CLI, SSH) as the primary example, and only supplement with OS-specific tools as needed.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation demonstrates a Windows bias by providing detailed examples and calculations specifically for Windows Containers, referencing Windows-specific SKUs (e.g., I1v2 Windows), and listing Windows-centric tools and ports (such as Visual Studio remote debugging and Web Deploy) without equivalent Linux examples or tools. Linux is mentioned only in passing, with no concrete examples or parity in guidance.

Recommendations:

Add equivalent examples and calculations for Linux Containers, including how IP address requirements may differ.
When referencing App Service plan SKUs, include both Windows and Linux variants, or clarify if guidance applies to both.
List Linux-relevant deployment and debugging tools/ports (e.g., SSH, SFTP, VS Code Remote) alongside Windows tools.
Provide Linux-specific notes or caveats where behaviors or requirements differ.
Ensure that all sample calculations, tables, and recommendations are presented for both Windows and Linux scenarios, or explicitly state when guidance is OS-agnostic.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation demonstrates a mild Windows bias. In sections where both Windows and Linux are relevant (such as SKU availability), Windows examples and commands are presented before Linux ones. The automation section provides both Azure CLI (cross-platform) and Azure PowerShell (Windows-centric) examples, but does not mention Bash scripting or Linux-native automation tools. The UI walkthroughs and screenshots are based on the Azure Portal, which is platform-agnostic, but there is no mention of Linux-specific considerations or parity checks.

Recommendations:

Present Linux and Windows options in parallel or alternate their order to avoid always listing Windows first.
Include Bash scripting examples alongside PowerShell for automation, especially for Linux users.
Explicitly mention that Azure CLI commands work on both Windows and Linux, and provide sample shell environments (e.g., Bash, zsh) where appropriate.
If there are any Linux-specific considerations or limitations, call them out explicitly.
Add a note or section on deploying and managing App Service plans from Linux environments, including any differences in experience or tooling.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ powershell_heavy

Summary:

The documentation is heavily focused on Windows-based Node.js applications running on Azure App Service, specifically using iisnode. All configuration, troubleshooting, and operational guidance is tailored to Windows environments, with exclusive references to Windows tools (IIS, iisnode, web.config, named pipes, Win32 error codes, Kudu CMD/PowerShell), and no mention of Linux equivalents or cross-platform approaches. There are no examples or instructions for Linux-based App Service environments.

Recommendations:

Provide equivalent guidance and examples for Node.js applications running on Azure App Service for Linux, including configuration, troubleshooting, and diagnostics.
Include Linux-specific tools and patterns (e.g., PM2, systemd, nginx, environment variables) alongside or before Windows-specific ones.
Offer parallel code/configuration snippets for both Windows (web.config/iisnode) and Linux (e.g., process.json for PM2, nginx config).
Reference Linux file paths, error logs, and diagnostic approaches (e.g., /home/LogFiles, journalctl, tailing logs) where appropriate.
Clarify at the top of the document that the content is Windows-specific, and link to a Linux-focused best practices page if available.
Avoid assuming the use of Windows-only features (like named pipes, Win32 error codes, web.config) without noting their absence or alternatives on Linux.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a mild Windows bias. Windows-related information and examples are often presented before Linux equivalents, and PowerShell scripting is given equal prominence to Azure CLI, but without any Linux shell (bash) scripting examples. The automation section provides both Azure CLI and PowerShell examples, but does not include a bash script or Linux-specific automation workflow. Additionally, the portal-based instructions do not clarify cross-platform differences, and the 'Development tools' section references UI elements without noting any OS-specific behaviors.

Recommendations:

Provide Linux shell (bash) script examples alongside Azure CLI and PowerShell, especially in the automation section.
When listing SKU availability commands, present Linux and Windows commands in parallel, or clarify that both are equally supported.
Explicitly mention any differences in portal experience or tooling between Windows and Linux where relevant.
Add a section or callout for Linux users, highlighting any unique considerations or best practices for Linux App Service plans.
Ensure that all scripting and automation guidance is cross-platform, or clearly indicate when a tool or workflow is Windows-specific.

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, and by providing detailed operational instructions and examples using Windows-style paths. There is a lack of Linux-specific examples or parity in instructions, and Windows patterns/tools are mentioned exclusively or with greater detail.

Recommendations:

Provide Linux file path examples (e.g., /home/site/wwwroot) alongside or before Windows paths in all relevant sections.
Include explicit Linux-specific instructions or notes where operational differences exist (such as file system permissions or path separators).
Ensure all deployment and troubleshooting steps reference both Windows and Linux environments equally, including directory creation and file placement.
Add Linux terminal command examples where appropriate, especially for manual steps (e.g., creating directories or files).
Review all references to Windows tools or patterns and ensure Linux alternatives are mentioned with equal prominence.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation page demonstrates a Windows bias by providing only PowerShell examples for per-app scaling, referencing Azure PowerShell cmdlets exclusively, and omitting equivalent CLI or Linux-native instructions. There are no Bash, Azure CLI, or cross-platform scripting examples, and the PowerShell approach is presented first and solely for command-line configuration.

Recommendations:

Add equivalent Azure CLI (az) examples for all PowerShell cmdlet instructions, as Azure CLI is cross-platform and widely used on Linux and macOS.
Include Bash scripting examples where appropriate, especially for configuring app settings or deploying ARM templates.
Explicitly mention that PowerShell examples can be run on any platform with PowerShell Core, or clarify platform requirements.
Reorder or parallelize sections so that PowerShell and CLI/Linux-native instructions are presented together, avoiding a 'Windows-first' impression.
Reference Linux tools or workflows where relevant, such as using curl or jq for REST API calls, or deploying with Terraform.

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, IIS logs), and providing examples or links that are Windows-centric. There is little to no mention of Linux-specific equivalents or guidance for Linux-based App Service environments, and PowerShell is referenced as the primary CLI tool for management. Diagnostic and troubleshooting steps are described in terms of Windows tools and patterns, with Linux parity missing throughout.

Recommendations:

Include Linux-specific instructions and examples for enabling diagnostics, collecting logs, and troubleshooting (e.g., reference Linux log file locations, use of SSH, and Linux-native tools).
When mentioning PowerShell, also provide equivalent Azure CLI (az) commands and Bash examples.
Clarify which features or steps apply to both Windows and Linux App Service plans, and note any differences.
Reference Linux equivalents for tools like Procdump (e.g., gcore, gdb, or dotnet-dump for .NET apps on Linux).
Provide links to Linux-focused documentation where available (e.g., enabling diagnostic logging on Linux App Service).
Avoid using Windows terminology (such as web.config, IIS, or DOS commands) without also mentioning Linux equivalents (such as appsettings.json, Kestrel, or Bash commands).

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation exhibits subtle Windows bias by referencing Azure Storage Explorer with a direct link to its Windows tab and not mentioning Linux alternatives or parity. There are no explicit Linux or cross-platform instructions for uploading files or generating SAS tokens, and the only GUI tool mentioned is Storage Explorer, which is often associated with Windows. All command-line examples use Azure CLI, which is cross-platform, but the lack of Linux-specific guidance or examples (such as using azcopy, native Linux tools, or Storage Explorer on Linux) may leave Linux users underserved.

Recommendations:

Explicitly mention that Azure Storage Explorer is available for Windows, macOS, and Linux, and provide links or instructions for all platforms.
Include alternative command-line methods for uploading files and generating SAS tokens, such as using azcopy or Azure CLI commands, which work on Linux.
Avoid linking directly to Windows-specific tabs or instructions; use platform-neutral links or provide parallel instructions for Linux/macOS.
Add a note or section for Linux users, highlighting any differences or additional steps required.
Where GUI tools are mentioned, suggest equivalent CLI workflows for users who prefer or require command-line operations.

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. It references Windows-specific tools (Visual Studio, Kudu, CMD, PowerShell), provides only Windows file paths and commands, and omits Linux-based equivalents or examples. There is no mention of how to perform these tasks on Linux-based App Service plans or containers, nor are Linux shell commands or tools referenced.

Recommendations:

Add equivalent Linux-based instructions and examples for each configuration task, especially for listing .NET Framework/Mono runtimes and accessing diagnostic logs.
Include Linux shell (bash) commands and file paths alongside CMD/PowerShell examples.
Clarify which instructions apply to Windows App Service plans and which to Linux, and provide parity in coverage.
Reference cross-platform deployment tools (such as Azure CLI, Git, or VS Code) in addition to Visual Studio.
Provide guidance for users deploying to Linux containers or App Service on Linux, including how to set environment variables and access logs.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation provides both Linux and Windows instructions for configuring server-level data sources in Tomcat, but the Windows section is longer, more detailed, and uses Windows-specific tools (PowerShell, .cmd files, Windows environment variables) without always providing Linux equivalents or parity in explanation. Windows instructions are more step-by-step and reference Windows tools and patterns (e.g., PowerShell scripts, .cmd startup files) extensively, while Linux instructions are more concise and assume familiarity with shell scripting and Linux package management. In some places, the Windows approach is described first or in more detail, and the Linux approach is less elaborated.

Recommendations:

Ensure that Linux and Windows sections are equally detailed, with step-by-step instructions and explanations for both platforms.
Where Windows-specific tools (e.g., PowerShell, .cmd) are used, provide Linux equivalents (e.g., Bash scripts) and explain their usage in similar depth.
Present Linux and Windows instructions in parallel or side-by-side, rather than giving more prominence or detail to Windows.
Avoid assuming more technical familiarity for Linux users; provide clear, beginner-friendly guidance for both platforms.
Where possible, use cross-platform tools (e.g., Azure CLI, Bash scripts) in examples, or provide both Windows and Linux command/script samples.
Review the order of presentation to avoid implicit prioritization of Windows approaches.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation demonstrates a Windows bias by prioritizing Windows-centric tools and workflows (e.g., Visual Studio, right-click actions, NuGet Package Manager) and omitting explicit Linux or cross-platform alternatives. There are no Linux-specific instructions or examples for common tasks such as file creation, package installation, or deployment, and the CLI instructions are referenced only as secondary options. The documentation assumes a GUI-based development environment typical of Windows, with no mention of Linux editors, terminal commands, or deployment nuances.

Recommendations:

Provide explicit Linux and cross-platform instructions for all steps, including file creation (e.g., using 'touch' and editors like 'vim' or 'nano'), package installation (e.g., using 'dotnet add package'), and deployment.
List CLI-based instructions before or alongside GUI-based (Visual Studio) instructions to ensure parity.
Reference cross-platform tools (e.g., VS Code, dotnet CLI) equally or before Windows-only tools.
Include screenshots or code snippets that show Linux terminal usage where appropriate.
Clarify that all steps can be performed on Linux and provide troubleshooting tips for common Linux-specific issues.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation demonstrates a Windows bias in several ways: Windows-specific deployment methods (Web Deploy) are described in detail, with explicit instructions to use Windows agents and references to IIS and web.config. Linux deployment is mentioned as an option, but Linux-specific examples, troubleshooting, or tools are lacking. The primary detailed example for deploying with Web Deploy is only for Windows, and the FAQ reinforces this by stating Web Deploy is only supported on Windows agents. There are no Linux shell or command-line examples, and Windows patterns (such as web.config and IIS) are referenced without Linux equivalents.

Recommendations:

Provide equivalent Linux deployment examples, such as using zip deploy or FTP/SFTP, and include Linux-specific troubleshooting steps.
When mentioning deployment methods like Web Deploy, also highlight and provide examples for Linux-friendly alternatives (e.g., Kudu REST API, zip deploy, or container-based deployments).
Avoid referencing Windows tools (e.g., IIS, web.config) without mentioning Linux equivalents (e.g., Nginx, Gunicorn, app.yaml for Python, etc.) where appropriate.
Ensure that all YAML and Classic pipeline examples show both Windows and Linux agent configurations, and clarify any differences in steps or requirements.
Include at least one end-to-end example for a Linux-based stack (e.g., Node.js or Python on Linux App Service) with Linux agent, including build, publish, and deploy steps.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a moderate Windows bias. While it does mention 'web app on Linux' in the introduction and uses Azure CLI (which is cross-platform) for most command-line examples, several aspects reveal a Windows-centric approach: PowerShell examples are always provided alongside CLI, sometimes with more detail; Windows-specific tools and configuration patterns (such as Web.config and IIS applicationInitialization) are referenced without Linux equivalents; and troubleshooting and advanced configuration sections assume a Windows environment (e.g., file paths, IIS rewrite rules). There are no explicit Linux-specific examples or notes for Linux-based App Service scenarios, and some features (like auto swap) are noted as unsupported on Linux, but without alternative guidance.

Recommendations:

Provide explicit Linux-specific examples or notes where features differ (e.g., clarify how to handle warm-up and swap on Linux-based App Service, or what configuration files/settings are relevant).
When referencing Windows-specific tools or configuration (such as Web.config, IIS, or PowerShell), add equivalent guidance for Linux (e.g., appsettings.json, startup scripts, or Bash/Cloud Shell commands).
In troubleshooting sections, include Linux-relevant file paths, logs, and error handling steps.
Where features are unsupported on Linux (e.g., auto swap), suggest alternative workflows or workarounds for Linux users.
Ensure parity in detail and clarity between PowerShell and CLI examples, and consider leading with CLI (cross-platform) examples rather than PowerShell (Windows-centric).

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation exhibits a moderate Windows bias, particularly in the .NET section, where Windows tools (Visual Studio, Azure PowerShell) are listed before cross-platform or Linux-native tools. The 'Next step' callout exclusively promotes deploying an ASP.NET app (a Windows-centric stack). In the Python section, example links default to 'windows' tabs, and PowerShell is offered as a primary automation tool in .NET. Linux-specific examples are present but often secondary or less emphasized, and in some stacks (e.g., PHP), only Linux is mentioned, but overall parity is inconsistent.

Recommendations:

Ensure that for every Windows tool or example (e.g., Visual Studio, PowerShell), a Linux equivalent (e.g., VS Code, Azure CLI, Bash) is provided and given equal prominence.
Avoid listing Windows tools first by default; alternate the order or group by platform.
In call-to-action/next-step sections, provide options for both Windows and Linux stacks, or make the next step stack-agnostic.
For Python and other cross-platform stacks, ensure that example links and tabs do not default to 'windows' but offer both 'windows' and 'linux' options equally.
Where PowerShell is mentioned, also mention Bash/Azure CLI equivalents.
Audit all quickstart and tutorial links to ensure Linux users are not required to adapt Windows-centric instructions.

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 PowerShell examples are always presented immediately after CLI, and there are no explicit Linux shell or Bash script examples beyond the basic nslookup and curl commands. The note about outbound IPv6 support is Windows-specific, and there is no mention of Linux-specific tools or parity in outbound IPv6 support. The documentation assumes familiarity with Windows-centric tools (PowerShell) and features, and does not provide Linux-first or Linux-specific guidance where differences exist.

Recommendations:

When presenting command-line examples, alternate the order of Azure CLI and PowerShell, or clearly indicate that Azure CLI is cross-platform and preferred for Linux/macOS users.
Explicitly state that Azure CLI commands work on Linux, macOS, and Windows, and provide Bash script examples for common tasks where appropriate.
Where outbound IPv6 support is Windows-only, clarify the lack of Linux support and provide a roadmap or workaround for Linux users if possible.
Include Linux-native tools (e.g., dig, ip, ifconfig) in examples where relevant, especially for network troubleshooting.
Add a section or callout summarizing any platform-specific limitations or differences, especially regarding outbound IPv6 support.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

Summary:

The documentation provides extensive Azure PowerShell examples and references, which are primarily Windows-centric. PowerShell is featured prominently alongside Azure CLI, and in some cases, PowerShell is the only scripting example provided for certain tasks (e.g., assigning user-assigned identities to Functions). There is no mention of Linux-specific shell commands or tools (such as Bash scripts or curl/wget for HTTP requests), and PowerShell is presented as a default automation tool, which may not be as familiar or available to Linux users. Additionally, PowerShell examples are sometimes given before or instead of more cross-platform alternatives.

Recommendations:

Add Bash or shell script examples for all tasks currently demonstrated with PowerShell, especially for token retrieval and identity assignment/removal.
Where HTTP requests are shown, provide curl or wget command-line examples in addition to PowerShell's Invoke-RestMethod.
Clarify that Azure CLI is fully cross-platform and, where possible, prefer it over PowerShell for automation examples.
Explicitly mention Linux/macOS compatibility in relevant sections, and ensure that all code snippets are runnable on those platforms.
For sections where PowerShell is the only option (e.g., assigning user-assigned identities to Functions), state the limitation clearly and provide any available workarounds for Linux users.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation exhibits a Windows-first bias in several areas: Windows paths and conventions are often mentioned before or instead of Linux equivalents (e.g., 'D:\home' before '/home'), Windows-specific tools and settings (such as MSDeploy, Web Deploy, and IIS) are referenced without always providing Linux alternatives, and some configuration examples use Windows environment variable syntax or reference Windows-only features. While there are sections for Linux (e.g., Oryx build, Linux-specific variables), Windows terminology and tools are generally foregrounded, and Linux examples or explanations are sometimes missing or less detailed.

Recommendations:

For every environment variable or feature that behaves differently on Windows and Linux, provide both Windows and Linux examples side by side.
When referencing file paths, always show both Windows (e.g., 'D:\home') and Linux ('/home') formats together.
Avoid using Windows environment variable syntax (e.g., '%HOME%') exclusively; include Linux syntax ('$HOME') as well.
When mentioning deployment tools (e.g., MSDeploy, Web Deploy), explicitly state their Linux alternatives or note if not available.
Ensure that Linux-specific build and deployment flows are as thoroughly documented as Windows ones, with equal detail and prominence.
Review all sections for references to Windows-only features or behaviors and clarify their applicability to Linux or provide Linux equivalents where possible.
In tables and lists, avoid placing Windows-specific information first by default; alternate or present both platforms equally.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation demonstrates a Windows-first bias: logging types and features are described for Windows in more detail and before Linux, with several logging types (web server logging, detailed error messages, failed request tracing) only available or documented for Windows. Linux instructions are less detailed and sometimes omitted. Windows-specific tools and formats (e.g., W3C log format, Log Parser, Web.config) are referenced without Linux equivalents.

Recommendations:

Provide Linux-specific examples and instructions for all logging types, or clearly state if a feature is unavailable on Linux.
Document Linux equivalents or alternatives for Windows-only tools and patterns (e.g., suggest open-source log viewers for Linux, explain how to access and interpret logs on Linux).
Present Windows and Linux instructions in parallel sections or tables to ensure parity and avoid Windows-first ordering.
Clarify any feature gaps between Windows and Linux, and link to relevant feature request or roadmap pages if Linux support is planned.
Expand code examples to include Linux-appropriate frameworks and logging libraries, not just ASP.NET and .NET.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation demonstrates a moderate Windows/Powershell bias. Powershell commands and Windows-centric tools (such as AzPowershell, Azure PowerShell, and .NET/NUnit with C#) are used or referenced frequently, sometimes without equivalent Linux/bash alternatives. Powershell is used in both GitHub Actions and Azure Pipelines examples, and the use of 'PowerShell@2' and 'pscore' script types further reinforce this. There are no explicit bash or Linux shell command examples, and Windows/PowerShell tools are often mentioned first or exclusively, especially for authentication and setup steps.

Recommendations:

Provide bash or sh equivalents for all PowerShell commands and scripts, especially for steps like authentication, dependency installation, and running Playwright tests.
Include Linux/macOS CLI examples (e.g., using Azure CLI instead of Azure PowerShell) alongside or before Windows/PowerShell examples.
Clarify when a step is cross-platform and when it is Windows-specific; avoid implying that PowerShell is required on Linux runners.
For .NET/NUnit sections, mention that .NET Core is cross-platform and provide explicit Linux/macOS instructions where relevant.
In workflow YAML examples, show both PowerShell and bash script blocks, or use shell-agnostic commands where possible.
Review all references to Windows tools and ensure Linux-native alternatives are documented and easy to find.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a moderate Windows bias. Windows-specific instructions and examples are consistently presented before their Linux equivalents (windows_first). There are several references to Windows tools and patterns, such as directory names and runtime strings, that are more familiar to Windows users (windows_tools). In a few places, Linux-specific details or troubleshooting steps are less emphasized or missing (missing_linux_example), and the Linux section sometimes uses less precise or inconsistent instructions compared to the Windows section.

Recommendations:

Alternate the order of Windows and Linux pivots throughout the documentation, or present both platforms side-by-side where possible, to avoid always prioritizing Windows.
Ensure that all examples, troubleshooting steps, and explanations are equally detailed for both Windows and Linux, including consistent directory structures and runtime naming conventions.
Where platform-specific commands or behaviors differ, provide explicit notes or callouts for both Windows and Linux users.
Review all images, screenshots, and portal navigation steps to ensure they are not Windows-centric and are equally applicable to Linux deployments.
Explicitly mention any differences in behavior, limitations, or requirements between Windows and Linux App Service environments.
Consider adding a summary table or section that highlights key differences and similarities between Windows and Linux deployment steps.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a bias toward Windows environments by referencing Windows-specific tools (such as SQL Server Management Studio and Visual Studio), presenting Windows/GUI-based workflows before mentioning any CLI or cross-platform alternatives, and omitting Linux-native or cross-platform equivalents for key steps (e.g., no mention of Azure Data Studio, VS Code, or Linux-compatible SQL tools). The instructions for publishing and database management are centered on Windows tools, and there is little guidance for users on Linux or macOS.

Recommendations:

Include examples using cross-platform tools such as Azure Data Studio and Visual Studio Code for database management and code publishing.
Provide explicit instructions for Linux/macOS users, including how to connect to Azure SQL Database using sqlcmd or Azure Data Studio on non-Windows platforms.
When referencing tools like SQL Server Management Studio or Visual Studio, also mention their cross-platform alternatives and provide parallel instructions.
Ensure that CLI-based workflows are presented as primary or co-equal options, not just as alternatives to Windows GUI tools.
Add notes or sections that address differences or additional steps required for Linux/macOS environments, especially for local debugging and publishing.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation demonstrates a Windows bias by providing only PowerShell commands for resource cleanup, referencing IIS (a Windows-only web server) for validation, and omitting Linux/CLI alternatives for these steps. There are no examples or instructions for Linux users, such as using Bash, Azure CLI, or Linux-based web servers for validation.

Recommendations:

Provide equivalent Azure CLI (az) commands for resource cleanup alongside the PowerShell example, as Azure CLI is cross-platform.
Include instructions for validating the deployment using a Linux-based web server (e.g., Apache or Nginx) in addition to IIS, or clarify how Linux users can test the deployment.
Add Bash shell examples for common operations where appropriate.
Ensure that references to tools or commands are platform-neutral or that both Windows and Linux alternatives are presented side by side.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation demonstrates a Windows-centric bias. Windows and PowerShell tools are prioritized or exclusively mentioned in several sections, especially for development environment setup and database permission granting. Visual Studio for Windows is described in detail, while Linux/macOS workflows are either missing, less detailed, or only referenced via Azure CLI. There are no explicit Linux-specific instructions for tasks like connecting to SQL Database or running migrations, and PowerShell/Windows tools are often the default or only example.

Recommendations:

Provide explicit Linux/macOS instructions for all steps, including connecting to Azure SQL Database (e.g., using sqlcmd on Linux, Azure Data Studio, or cross-platform tools).
Ensure that examples using PowerShell or Windows-specific tools are accompanied by equivalent Bash/Azure CLI or cross-platform alternatives.
Reorder sections so that cross-platform or CLI-based approaches are presented before or alongside Windows/PowerShell methods.
Include guidance for developing and debugging with .NET on Linux/macOS (e.g., using VS Code, JetBrains Rider, or CLI tools), not just Visual Studio for Windows.
Clarify that all steps can be performed on Linux/macOS where possible, and highlight any platform-specific limitations.
Add migration and publishing instructions for Linux/macOS environments, using dotnet CLI and Git instead of only Visual Studio UI.

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) and its Test Explorer are featured prominently as the GUI workflow, with no mention of Linux-native editors or CLI-only workflows. The only IDE-based instructions are for VS Code, which is most popular on Windows. There are no explicit Linux-specific instructions, screenshots, or terminal examples (e.g., bash vs PowerShell). The .NET/NUnit runner instructions use PowerShell syntax for package installation and do not mention Linux-specific .NET usage or shell commands. There are no references to Linux tools, shells, or package managers, and all screenshots are from the Azure Portal, which is OS-agnostic but the workflow assumes a GUI, which is more common on Windows.

Recommendations:

Include explicit Linux/macOS CLI examples alongside or before Windows/PowerShell examples (e.g., show both bash and PowerShell commands for .NET and npm usage).
Add a section or note about running Playwright tests in Linux environments, including any differences in environment variable setup or file paths.
Provide alternative instructions for popular Linux editors (such as Vim, Emacs, or JetBrains IDEs) or clarify that VS Code is cross-platform.
Show at least one screenshot or terminal output from a Linux shell to demonstrate parity.
Mention Linux package managers (apt, yum, etc.) where relevant, especially for installing dependencies like Node.js or .NET SDK.
Clarify that all instructions are cross-platform unless otherwise noted, and explicitly state any OS-specific caveats.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias in several ways: Windows-specific concepts (registry, services, file paths) are often discussed in more detail or appear first; Windows tools and patterns (registry keys, Windows services, c:\ paths) are highlighted, sometimes without Linux equivalents or with less detail. Powershell/Windows command syntax is used for both OS types in code blocks, and example queries and alerting scenarios are predominantly Windows-centric, with only a few Linux references. Linux-specific features and examples are less detailed or missing.

Recommendations:

Ensure Linux examples are provided with equal detail and prominence as Windows examples throughout the documentation.
When listing supported features or configuration steps, alternate the order between Windows and Linux or present them side-by-side.
Provide Linux-specific command-line examples using native Linux shells (e.g., bash), not just az CLI in PowerShell context.
Expand Linux daemon/package tracking sections to match the depth of Windows registry/services coverage, including example daemon names, config files, and typical use cases.
Include Linux file path examples (e.g., /etc/hosts) in alerting/query scenarios alongside Windows paths.
Clarify any Windows-only limitations or features, and explicitly state Linux equivalents or lack thereof.
Add more screenshots and walkthroughs for Linux environments, not just Windows.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation demonstrates a moderate Windows bias. PowerShell is consistently presented as a primary automation example, often before Azure CLI. All automation examples use either Azure PowerShell or Azure CLI, with no mention of Bash, shell scripting, or Linux-native tools. The documentation refers to PowerShell cmdlets and patterns, which are more familiar to Windows users, and does not provide parity for Linux users beyond the Azure CLI. There are no explicit Linux-specific instructions or examples, and the sample code references (e.g., StackExchange.Redis, ASP.NET) are .NET-centric, further reinforcing a Windows-oriented perspective.

Recommendations:

Provide Bash or shell script equivalents for all PowerShell examples, especially for common scaling operations.
Explicitly mention that Azure CLI commands work cross-platform and, where relevant, show them in a Bash context (e.g., with environment variables or piping).
Add a section or callout for Linux users, clarifying that all operations can be performed from Linux/macOS using Azure CLI, and link to Azure CLI installation instructions for those platforms.
Include at least one example using a Linux-native tool (e.g., curl with the Azure REST API) for advanced users.
Balance .NET/PowerShell sample code with Python or Node.js examples, which are more common in Linux environments.

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 gives equal prominence to PowerShell (a Windows-centric tool) without mentioning Linux-specific tools or workflows. There are no explicit Linux shell (bash) examples, and PowerShell is presented as a primary automation method alongside CLI, which may not be as familiar or available to Linux users. The document also lacks any mention of Linux-specific considerations or parity checks for cross-platform users.

Recommendations:

Add explicit bash shell examples for all CLI commands, showing usage in a typical Linux environment.
Clarify that Azure CLI is fully cross-platform and can be used on Windows, Linux, and macOS, while PowerShell examples are primarily for Windows users (unless PowerShell Core is being targeted).
Provide notes or links for installing and using Azure CLI on Linux.
If PowerShell Core (cross-platform) is supported, clarify this and provide installation instructions for Linux/macOS users.
Consider including a section or callout for Linux/macOS users, highlighting any differences or confirming parity.
Ensure screenshots and UI descriptions are not Windows-specific (e.g., avoid showing only Windows-style UI if there are differences).

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation demonstrates a moderate Windows bias. Windows is mentioned first or with special emphasis in several sections, such as recommending Windows Subsystem for Linux (WSL) as the primary way to use redis-cli on Windows, and referencing Windows Terminal. Azure PowerShell is listed alongside Azure CLI for retrieving cache keys, and is mentioned before the Azure portal in some places. There are no Linux-specific tools or shell examples beyond the initial installation, and the guidance for Windows users is to use Linux tools via WSL rather than native Windows solutions.

Recommendations:

Provide native redis-cli installation or usage instructions for Windows without requiring WSL, such as using precompiled binaries or Docker.
When listing methods to retrieve cache keys, alternate the order or mention Azure CLI and Azure PowerShell together, and ensure parity in example depth.
Include explicit Linux and macOS terminal examples where relevant, not just generic 'console' blocks.
Avoid recommending Windows-specific tools (like Windows Terminal) unless also mentioning Linux/macOS equivalents.
Consider a dedicated section for each OS (Linux, Windows, macOS) to ensure equal clarity and visibility.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation demonstrates a moderate Windows bias. Windows-specific tools and configuration steps (such as Visual Studio, PowerShell, and Windows-specific CLI flags) are often mentioned before or more prominently than their Linux equivalents. Some deployment and configuration examples are Windows-first or reference Windows-specific concepts before Linux. In several places, Linux instructions are present but less detailed or appear after Windows instructions. There is a lack of explicit Linux shell (bash) or cross-platform CLI examples in some sections, and PowerShell is referenced as a primary automation tool.

Recommendations:

Ensure all CLI examples are provided in both Windows (PowerShell/CMD) and Linux (bash) syntax, using tabs or side-by-side formatting.
When listing tools or workflows (e.g., Visual Studio, Visual Studio Code, Azure CLI, PowerShell), present cross-platform options first or equally, rather than Windows-only or Windows-first.
Where PowerShell is mentioned, also provide equivalent bash or shell scripts for Linux users.
In deployment and configuration sections, ensure Linux and container scenarios are described with equal detail and prominence as Windows scenarios.
Add explicit notes or callouts for any Windows-only features, and provide Linux alternatives or workarounds where possible.
Review all references to Visual Studio and ensure Visual Studio Code and CLI-based workflows are equally documented and discoverable.
Audit for any missing Linux-specific troubleshooting or debugging guidance, and add parity where gaps exist.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation demonstrates a mild Windows bias. It references IIS (a Windows-only web server) as the example application for testing, and provides a link to IIS setup instructions, but does not mention or provide examples for Linux-based web servers (such as Apache or Nginx). There are no explicit PowerShell or Windows command-line examples, but the only application setup guidance is Windows-centric. No Linux equivalents or cross-platform alternatives are discussed.

Recommendations:

Include Linux-based web application examples (e.g., Apache, Nginx, or a simple Python/Node.js app) alongside IIS for testing the integration.
Provide links or brief instructions for setting up a test web application on Linux, similar to the IIS setup link.
Explicitly mention that the solution is platform-agnostic and can be used with both Windows and Linux back-end applications.
Where possible, use neutral language (e.g., 'web application' instead of 'IIS app') and provide parity in examples and references.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

Summary:

The documentation provides both Azure CLI and PowerShell examples for managing access restrictions, but PowerShell examples are often presented first and are more detailed in some advanced scenarios. There is a notable emphasis on PowerShell, which is traditionally associated with Windows environments, even though Azure CLI is cross-platform. No Linux-specific tools or shell scripting examples are provided, and there is no mention of Linux command-line environments or considerations, despite the documentation stating support for Linux apps and containers.

Recommendations:

Present Azure CLI examples before PowerShell examples, as Azure CLI is cross-platform and more familiar to Linux users.
Add explicit Bash/shell script examples for common scenarios, especially for advanced use cases currently only shown in PowerShell.
Include notes or tips for Linux users, such as how to use Azure CLI in native Linux shells or integrate with other Linux tools.
Clarify that PowerShell Core is available cross-platform, but highlight that Azure CLI is the default for Linux environments.
Where possible, provide parity in example complexity and coverage between Azure CLI and PowerShell sections.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows-first bias by referencing the Windows file path (C:\home\site\wwwroot) as the default example for where to place the configuration file, and only later noting the Linux equivalent in a note. There are no Linux-specific examples or screenshots, and the Linux path is only mentioned as a constraint rather than as a primary example. No Linux command-line or deployment examples are provided.

Recommendations:

Present both Windows and Linux file paths side-by-side in the main instructions, not just in a note.
Include explicit Linux examples (e.g., using /home/site/wwwroot/auth.json) in step-by-step instructions and code snippets.
If referencing deployment locations or commands, provide both Windows and Linux variants.
Consider adding a table or section that summarizes differences and best practices for both platforms.
Add Linux-specific troubleshooting or tips where relevant, to ensure parity and clarity for Linux users.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page focuses exclusively on assessing ASP.NET web apps, which are traditionally associated with Windows environments. There is no mention of Linux-based .NET web apps, nor are there examples or guidance for assessing .NET apps running on Linux. All referenced tools and tutorials implicitly assume a Windows context, and there is no parity for Linux users.

Recommendations:

Include explicit guidance and examples for assessing .NET web apps running on Linux, such as ASP.NET Core apps deployed on Linux servers.
Mention and link to any tools or scripts that support Linux environments, or clarify if the assessment process is Windows-only.
Add a section comparing assessment steps or considerations for both Windows and Linux .NET web apps.
Ensure referenced tutorials and best practices include Linux scenarios where applicable.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page presents Windows container SSH access first and describes it as requiring no special configuration, while Linux containers are described as needing extra steps. The Windows section lacks any CLI or command-line examples (since they're not supported), but the Linux section provides detailed CLI instructions and examples. There are no PowerShell or Windows command-line examples, but the ordering and framing may give the impression that Windows is simpler or preferred. There is also a lack of parity in the level of detail: Linux users get step-by-step CLI instructions, while Windows users are told only that browser SSH is supported.

Recommendations:

Present Linux and Windows instructions in parallel, with equal detail and prominence.
Clarify up front that SSH via CLI is only supported for Linux containers, and explain why this is the case.
If possible, provide equivalent command-line or automation options for Windows containers, or explicitly state their absence and suggest alternatives.
Avoid language that frames one platform as simpler or requiring less effort unless this is a technical limitation, and explain the reasons for any differences.
Consider adding a summary comparison table of SSH access methods for both Linux and Windows containers.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page exhibits a mild Windows bias by referencing Windows first in quickstart links and not providing explicit Linux-specific instructions or examples for environment setup, deployment, or tooling. While the content is generally cross-platform (Python/Flask), it assumes Azure portal or Windows-centric workflows and omits Linux command-line or deployment examples.

Recommendations:

Ensure that all quickstart and setup links include both Windows and Linux tabs or examples, or default to neutral (cross-platform) instructions.
Explicitly mention and provide Linux/macOS equivalents for any environment setup, deployment, or configuration steps (e.g., using Bash, Linux file paths, or Linux-specific Azure CLI usage).
If referencing the Azure portal or Visual Studio, also mention VS Code and command-line deployment options for Linux users.
Add a section or callouts for common Linux development environments and how to adapt environment variable setup, file permissions, and local testing.
Review all code snippets and instructions to ensure they are not implicitly Windows-specific (e.g., file paths, command syntax).

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation assumes the use of GitHub Codespaces and .NET, which are cross-platform, but all terminal instructions and deployment steps are generic and do not mention or provide examples for Linux environments, local development, or non-Windows shells. There is an implicit bias toward Windows/Visual Studio workflows (e.g., 'Open in Browser'), and no explicit mention of Linux-specific considerations or alternative tooling. The instructions do not address running or deploying the app outside of Azure App Service, which is often more common in Linux environments.

Recommendations:

Provide explicit instructions for running the sample locally on Linux (e.g., Ubuntu), including prerequisites such as installing the .NET SDK and any required dependencies.
Include terminal commands that are shell-agnostic or provide both PowerShell/Command Prompt and Bash equivalents where relevant.
Mention and demonstrate how to use the sample with local development environments on Linux and macOS, not just Codespaces or Azure.
Clarify that all steps can be performed on Linux and macOS, and note any differences (such as file paths or environment variable syntax).
If referencing 'Open in Browser', provide alternatives for Linux users (e.g., using xdg-open or open commands).
Add a note about deploying to Azure App Service for Linux, and mention that App Service supports both Windows and Linux hosting.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation demonstrates per-environment configuration using Azure App Configuration in the context of an ASP.NET Core application. It references modifying 'launchSettings.json' and uses .NET CLI commands, which are cross-platform, but the workflow and examples are tailored to Visual Studio/Windows development patterns. There are no explicit Linux or cross-platform environment variable setting examples (e.g., using bash or export), and the only method shown for changing environments is via 'launchSettings.json', which is primarily used in Windows/Visual Studio workflows.

Recommendations:

Include instructions and examples for setting environment variables on Linux/macOS (e.g., using 'export ASPNETCORE_ENVIRONMENT=Production' in bash).
Mention alternative ways to set environment variables outside of 'launchSettings.json', such as through shell commands or CI/CD pipelines.
Clarify that the .NET CLI commands are cross-platform and can be run on Windows, Linux, or macOS.
Add a note or section for developers using Linux or macOS, highlighting any differences or additional steps required.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

Summary:

The documentation provides environment variable setup instructions for all major platforms (Windows Command Prompt, PowerShell, macOS/Linux), but consistently lists Windows (cmd and PowerShell) before Linux/macOS. PowerShell and Windows Command Prompt commands are given equal or greater prominence than bash equivalents, and the use of setx (a Windows-specific tool) is described in detail, including the need to restart the command prompt. There are no missing Linux examples, but the ordering and emphasis subtly prioritize Windows tooling and patterns.

Recommendations:

Alternate the order of platform-specific instructions so that Linux/macOS is listed first in some sections, or present all platform instructions in parallel tabs to avoid implicit prioritization.
Avoid giving extra explanatory detail to Windows-specific tools (e.g., setx and restart) unless similar context is provided for Linux/macOS.
Where possible, use cross-platform commands (such as 'env' or 'printenv') in examples, or clarify that the Go application will work identically on all platforms once environment variables are set.
Consider adding a note at the top stating that all major platforms are supported and that instructions are provided for each.

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation generally maintains parity between Windows and Linux, especially in the configuration commands and explanations. However, in the section 'Configure name resolution behavior', the table lists 'Windows default value' before 'Linux default value', which is a subtle form of Windows-first bias. There are no PowerShell-specific examples, Windows-only tools, or missing Linux examples. The only other Windows-specific mention is in the limitations section, which is appropriate context.

Recommendations:

In the configuration table, consider listing Linux and Windows defaults in parallel columns or in alphabetical order (e.g., 'Linux default value' before 'Windows default value') to avoid implicit prioritization.
If possible, provide explicit notes or examples for both Windows and Linux where behaviors differ, even if the difference is only in default values.
Continue to avoid Windows-only tooling (such as PowerShell) in examples, and maintain the use of cross-platform tools like Azure CLI.

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation page lists .NET and ASP.NET Core libraries (which are primarily associated with Windows development) first in the configuration provider libraries table, with their samples and release notes prominently linked. There are no explicit Windows-only tools or PowerShell examples, but the ordering and emphasis on .NET/Windows-centric frameworks before cross-platform or Linux-native stacks (such as Python, JavaScript, Go) suggests a subtle 'windows_first' bias. There are no Linux-specific examples, tools, or guidance, nor are Linux or cross-platform usage patterns highlighted.

Recommendations:

Reorder the configuration provider libraries table to alternate or group by language family (e.g., interpreted, compiled, JVM-based) rather than placing .NET/Windows-centric libraries first.
Explicitly mention the cross-platform nature of the .NET Standard and .NET Core libraries, clarifying that they work on Linux and macOS as well as Windows.
Add Linux-specific or cross-platform usage notes or examples, especially for popular Linux deployment scenarios (e.g., Docker, Kubernetes, CLI usage on Linux).
Ensure that samples and documentation links for each provider include Linux-compatible instructions or highlight any OS-specific considerations.
If possible, add a section or callout that addresses platform compatibility and best practices for both Windows and Linux environments.

Create pull request

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