Scan Details - Linux-first Docs for Azure

204

Pages Scanned

42

Pages Flagged

204

Changed Pages

20.6%

% Pages Flagged

Live Progress

🔴 Connecting...

0%

Phase: discovery

Processing: Initializing...

Activity Feed

00:00:57 Scan started

Scan Information

Started At: 2025-08-23 00:00:57

Finished At: In Progress

Status: in_progress

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

Current Phase: discovery

Problematic Pages

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation demonstrates a mild Windows bias. While it states that Azure CLI commands can be run in both PowerShell and bash, it does not provide any explicit Linux/bash-specific examples or address Linux-specific considerations. The mention of PowerShell precedes bash, and there are no Linux-native tools or troubleshooting steps. The documentation assumes parity but does not demonstrate it with concrete examples or screenshots from Linux environments.

Recommendations:

Provide explicit bash/Linux command examples where variable syntax or behavior differs from PowerShell.
Include screenshots or terminal output from Linux environments to illustrate cross-platform usage.
Mention Linux-native tools or troubleshooting steps if applicable.
When referencing shells, alternate the order (e.g., 'bash or PowerShell') or clarify that both are equally supported.
Add a note confirming that all steps and UI are identical on Linux, or highlight any differences if they exist.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias by presenting Azure PowerShell instructions before Azure CLI, referencing PowerShell-specific cmdlets for status checks (even in CLI sections), and omitting explicit Linux or Bash shell examples. The workflow and screenshots are oriented toward the Azure Portal UI, which is platform-agnostic, but the command-line guidance prioritizes Windows-native tools and patterns.

Recommendations:

Present Azure CLI (cross-platform) instructions before or alongside PowerShell examples to avoid implying Windows-first workflows.
In CLI sections, use 'az' commands exclusively for both registration and status checks, rather than referencing PowerShell cmdlets for status.
Include explicit Bash or shell script examples for Linux users, especially for automation scenarios.
Where possible, clarify that Azure CLI commands work on Windows, Linux, and macOS, and provide sample shell prompts (e.g., $ for Bash, PS> for PowerShell) to reinforce cross-platform applicability.
Add links or references to Linux-specific guidance for related tasks (e.g., using Azure CLI on Linux, installing prerequisites, troubleshooting).

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias primarily through the exclusive use of Azure PowerShell commands and references to PowerShell scripts for migration, without providing equivalent Azure CLI (cross-platform) or Bash examples. The registration and unregistration instructions for the Basic SKU preview are shown only with PowerShell cmdlets, and migration guidance points to a PowerShell script. There are no Linux-specific or cross-platform command-line examples, and the CLI instructions shown are actually PowerShell commands, not Azure CLI/Bash, despite being labeled as 'azurecli-interactive'.

Recommendations:

Provide Azure CLI (az) command examples alongside or before PowerShell examples for all management tasks, including registration, unregistration, and migration.
Clarify and correct code block labels—ensure 'azurecli-interactive' blocks contain actual Azure CLI commands, not PowerShell.
Reference Bash or shell scripting alternatives for migration tasks, or provide links to cross-platform tools/scripts.
Explicitly state that all features and management operations are available and supported on Linux/macOS as well as Windows, where applicable.
Where PowerShell scripts are referenced (e.g., for migration), provide or link to equivalent Azure CLI or Bash scripts, or note if none exist.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a bias toward Windows by providing only PowerShell commands for resource cleanup and configuring backend virtual machines with IIS (a Windows web server). There are no Linux-specific examples, such as using Azure CLI for cleanup or deploying Linux-based backend VMs (e.g., with Nginx or Apache). The only command-line example is PowerShell, and the backend validation relies on IIS, which is Windows-specific.

Recommendations:

Include Azure CLI examples for resource cleanup (e.g., az group delete) alongside or before PowerShell commands.
Provide instructions or template modifications for deploying Linux-based backend VMs (e.g., Ubuntu with Nginx or Apache) in addition to Windows/IIS.
Show how to validate the deployment using a Linux-based web server (e.g., by browsing to a default Nginx/Apache page).
When referencing command-line tools, present cross-platform options (CLI and PowerShell) or clearly indicate which is platform-specific.
Consider alternating the order of examples or providing parallel instructions for both Windows and Linux users.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation is heavily biased towards Windows and PowerShell usage. All examples use Azure PowerShell cmdlets and Windows-specific tools (such as New-SelfSignedCertificate and Export-PfxCertificate), with no mention of Bash, Azure CLI, or Linux-compatible alternatives. The instructions assume a Windows environment (e.g., file paths like c:\appgwcert.pfx), and there are no parallel Linux or cross-platform examples provided.

Recommendations:

Provide equivalent Azure CLI (az) command examples alongside PowerShell for each step, as Azure CLI is cross-platform and widely used on Linux and macOS.
For certificate creation, include Linux/macOS instructions using OpenSSL to generate self-signed certificates and export to .pfx format.
Use platform-agnostic file paths (e.g., ./appgwcert.pfx) or clarify when a path is OS-specific.
Explicitly state that the tutorial can be followed from Windows, Linux, or macOS, and provide prerequisites and setup instructions for each OS.
Where PowerShell is required, mention PowerShell Core (pwsh), which is cross-platform, and provide guidance for installing and running it on Linux/macOS.
Add a section or callouts for users who prefer Bash scripting or other shells, referencing relevant documentation.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation page demonstrates a strong Windows bias by focusing exclusively on migration scenarios and tools for ASP.NET web apps running on Windows/IIS servers. All migration tools and scripts referenced are for Windows (including MSI installers and PowerShell scripts), with no mention of Linux-based hosting environments, migration from Linux servers, or Linux command-line examples. The documentation does not provide parity for Linux users or address migration of .NET apps hosted on Linux platforms.

Recommendations:

Include migration guidance and tools for .NET apps hosted on Linux (e.g., Apache, Nginx, Kestrel).
Provide Linux-specific examples and command-line instructions (e.g., Bash scripts, CLI commands) alongside or before Windows/PowerShell examples.
Reference or develop migration tools that support Linux environments, and document their usage.
Clarify in the introduction that the current tools are Windows-centric, and provide links or guidance for Linux users where possible.
Highlight any limitations or future plans for Linux support in the migration tooling.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page exhibits subtle Windows bias. While it is generally cross-platform, it references Windows-specific configuration files (web.config), tools (iisnode), and patterns before or instead of Linux equivalents. Linux-specific instructions are minimal and not consistently provided alongside Windows examples.

Recommendations:

Provide Linux-specific configuration guidance wherever Windows-specific files (like web.config) are mentioned. For example, explain how to configure auto-healing or similar features for Linux-based App Service plans.
When referencing tools like iisnode (Windows/IIS-specific), also mention and provide guidance for Linux process managers (e.g., PM2, systemd) for Node.js apps.
Ensure that examples and troubleshooting steps are given for both Windows and Linux App Service environments, especially in sections about configuration, diagnostics, and process management.
Explicitly state when a feature or recommendation is Windows-only, and offer Linux alternatives or workarounds where possible.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation demonstrates some Windows bias by presenting Azure PowerShell automation after Azure CLI, referencing PowerShell as a primary scripting tool, and using terms and screenshots that are more familiar to Windows users. While Linux is mentioned (e.g., Linux containers, --linux-workers-enabled), there are no Linux shell-specific examples, and the automation section does not provide Bash or Linux-native scripting patterns. The portal instructions and screenshots are platform-neutral, but the scripting focus leans toward Windows tools.

Recommendations:

Add explicit Bash or Linux shell script examples alongside Azure PowerShell, especially in the automation section.
Clarify that Azure CLI commands can be run on both Windows and Linux, and provide sample shell scripts for Linux users.
When mentioning PowerShell, also mention Bash or other Linux-native scripting environments to ensure parity.
Ensure that any references to tools or patterns (such as PowerShell) are balanced with Linux equivalents, or note when a tool is cross-platform.
Consider including a section or call-out specifically for Linux users, highlighting any differences or best practices.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a moderate Windows bias. Windows terminology and tools (such as Azure PowerShell) are presented prominently and sometimes before Linux equivalents. While both Windows and Linux SKU availability commands are shown, automation examples focus on Azure CLI and Azure PowerShell, with no mention of Linux-native scripting (e.g., Bash) or deployment patterns. The use of the Azure portal is described in a way that is platform-neutral, but the automation and scripting sections lean toward Windows-centric tools and workflows.

Recommendations:

Add explicit Bash scripting examples for Linux users alongside PowerShell examples in the automation section.
Clarify that Azure CLI commands are cross-platform and can be used on Linux, macOS, and Windows.
Include references to Linux-native tools or workflows where relevant (e.g., Bash scripts, deployment via Linux terminals).
Ensure that Linux examples are presented with equal prominence and, where possible, before or alongside Windows examples.
Mention that the Azure portal is accessible from any OS, and highlight any OS-specific considerations if they exist.

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 connectivity testing without equivalent Linux commands. Some features, such as the Hybrid Connection Manager GUI, are only available on Windows, and this is noted, but Linux alternatives are not always described with equal depth. Troubleshooting and connectivity testing examples are Windows-centric, and Linux users are sometimes directed to generic alternatives or left to infer equivalent steps.

Recommendations:

Provide Linux-first or parallel Linux examples alongside Windows instructions, especially for common tasks like connectivity testing (e.g., show 'nc' or 'telnet' commands as alternatives to PowerShell's Test-NetConnection).
Include Linux screenshots or terminal output where Windows GUI screenshots are shown, or at least provide equivalent CLI walkthroughs.
Expand troubleshooting steps to include Linux-specific commands and procedures, such as using 'ss', 'netcat', or 'curl' for network diagnostics.
Where features are Windows-only (e.g., GUI tools), offer detailed Linux CLI alternatives and explicitly note any limitations or workarounds.
Ensure that installation and upgrade instructions for Linux are as detailed and prominent as those for Windows, including package dependencies and service management.
Review the order of presentation so that Linux and Windows are given equal prominence, rather than consistently listing Windows first.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation demonstrates a Windows bias primarily by providing a PowerShell script as the only automation example for identifying impacted Azure Traffic Manager profiles (Scenario 2). There are no equivalent Bash, Azure CLI, or cross-platform script examples for Linux/macOS users. The instructions for running the script explicitly reference PowerShell, and there is no mention of alternatives or parity for non-Windows environments. While other sections use Azure CLI and REST API (which are cross-platform), the only automation script provided is Windows-centric, and the PowerShell approach is presented first and exclusively.

Recommendations:

Provide equivalent Bash or Azure CLI scripts for Linux/macOS users to identify non-Azure Traffic Manager endpoints, or at least reference how to achieve the same result using cross-platform tools.
When recommending scripts or automation, offer both PowerShell and Bash (or CLI) examples, and clarify their platform compatibility.
Explicitly mention that the PowerShell script can be run on PowerShell Core (which is cross-platform) if applicable, or provide installation guidance for non-Windows users.
Adopt a 'platform-neutral' approach by presenting Azure CLI or REST API examples before or alongside PowerShell scripts.
Audit future documentation for similar scenarios where only Windows/PowerShell tooling is referenced, and ensure Linux/macOS parity is considered.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page exclusively discusses discovery of .NET web apps hosted on IIS web servers within VMware environments, which are Windows-centric technologies. There is no mention of Linux-based hosting scenarios (e.g., .NET apps on Apache, Nginx, or Kestrel), nor are there examples or guidance for discovering .NET apps on Linux servers. All tools and workflows referenced (Azure Migrate appliance, IIS) are Windows-specific.

Recommendations:

Include information about discovering .NET web apps hosted on Linux servers, such as those running on Apache, Nginx, or Kestrel.
Provide parity in examples and workflows for both Windows (IIS) and Linux-based hosting environments.
Mention any Azure Migrate capabilities or limitations for Linux-hosted .NET apps, or clarify if such scenarios are unsupported.
Add links to documentation or tools relevant for Linux-based .NET app discovery and migration.
Explicitly state the scope of the documentation if it is intentionally limited to Windows/IIS, and provide references for Linux users.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ powershell_heavy

Summary:

The documentation is heavily focused on Windows-based Azure App Service environments, specifically those using iisnode. All configuration and troubleshooting steps reference Windows concepts, tools, and file paths (e.g., node.exe, web.config, named pipes, Win32 error codes, d:\home\LogFiles). Examples and instructions are provided only for Windows environments, with no mention of Linux-based Azure App Service or cross-platform alternatives. Tools like Kudu are referenced with CMD/PowerShell, and there is no parity for Bash or Linux-native workflows.

Recommendations:

Add equivalent sections and examples for Linux-based Azure App Service environments, including configuration, troubleshooting, and file locations.
Provide Linux/Bash command-line examples in addition to (or instead of) CMD/PowerShell, and reference Linux-native tools where appropriate.
Clarify early in the document that the content is specific to Windows App Service, and provide links or references to Linux-focused documentation for Node.js on Azure.
Where possible, use cross-platform Node.js concepts and tools (such as PM2 for process management) and avoid Windows-specific terminology (e.g., node.exe, Win32 error codes) unless necessary.
Include troubleshooting steps and log file locations for Linux-based deployments (e.g., /home/LogFiles, /var/log, etc.).

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a mild Windows bias by referencing Windows-specific tools (Azure Storage Explorer) and providing instructions that are either Windows-centric or lack Linux/macOS alternatives. The Storage Explorer SAS generation link is explicitly for Windows, and there is no mention of Linux-compatible tools or workflows for uploading files or generating SAS tokens. All command-line examples use Azure CLI, which is cross-platform, but the absence of Linux-specific guidance or parity in tooling references can disadvantage Linux users.

Recommendations:

Include instructions or links for using Azure Storage Explorer on Linux/macOS, or mention its cross-platform availability if applicable.
Provide alternative methods for uploading files and generating SAS tokens using cross-platform tools such as the Azure CLI or azcopy, with explicit examples.
Avoid labeling links or sections as 'Windows' unless there is a parallel for other operating systems, or provide equivalent Linux/macOS tabs or notes.
Audit the documentation for other Windows-centric patterns and ensure Linux users have clear, first-class guidance for all steps.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation page demonstrates a strong Windows bias. It exclusively references Windows-based deployment patterns, tools, and file paths (e.g., Kudu CMD/PowerShell, D:\ paths, Visual Studio publishing). There are no Linux-specific instructions, examples, or mentions of Linux-based App Service environments. The guidance assumes a Windows hosting environment throughout, omitting Linux equivalents for runtime inspection, configuration, and diagnostics.

Recommendations:

Add parallel instructions and examples for Linux-based App Service environments, 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 inspection and environment variable access.
Mention and demonstrate deployment workflows that are common on Linux (e.g., using dotnet CLI, VS Code, or GitHub Actions) alongside Visual Studio.
Clarify in each section whether the instructions apply to Windows, Linux, or both, and provide links to Linux-specific documentation where available.
Provide guidance on accessing logs and debugging information in Linux containers or App Service on Linux, not just via Windows tools like Kudu CMD/PowerShell.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

Summary:

The documentation provides both Linux and Windows instructions for configuring data sources in Tomcat and JBoss on Azure App Service. However, the Windows section relies heavily on PowerShell scripts and Windows-specific patterns (such as .cmd files, %HOME% paths, and Windows environment variables), while the Linux section uses shell scripts and Linux tools. The Windows instructions are more verbose and detailed, with step-by-step PowerShell automation, whereas Linux instructions are more concise and assume familiarity with shell scripting. The documentation sometimes presents Windows tooling and patterns before Linux equivalents, and the Windows section uses Windows-native tools exclusively for configuration tasks.

Recommendations:

Provide equivalent Linux shell script examples for every PowerShell script shown for Windows, ensuring parity in automation and clarity.
Where Windows-specific tools (e.g., PowerShell, .cmd files) are used, offer Linux alternatives (e.g., bash scripts) side-by-side.
Standardize the structure and depth of instructions for both platforms, so Linux users receive equally detailed guidance.
Avoid presenting Windows tools or patterns before Linux equivalents in sections that apply to both platforms; use parallel presentation or platform-specific tabs.
Explicitly mention cross-platform considerations and differences at the start of each section to help users navigate platform-specific steps.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows-first bias by presenting Windows container information and instructions before Linux, despite the page title listing Linux first. The Windows section is brief and only mentions browser-based SSH, while the Linux section provides detailed CLI-based SSH instructions and examples. There is a lack of parity in example depth and tool coverage: Windows users are not given CLI or PowerShell alternatives, and Linux users are not given browser-based SSH instructions. The documentation also refers to Windows containers as requiring 'no modifications' while Linux containers require 'additional configurations', potentially implying Windows is easier by default. Furthermore, Windows tools and patterns (browser SSH) are mentioned exclusively for Windows, with no equivalent CLI/PowerShell guidance.

Recommendations:

Provide equivalent CLI or PowerShell instructions for Windows containers, or explicitly state their absence and any workarounds.
Ensure both Windows and Linux sections have similar depth and example coverage (e.g., both should cover browser-based SSH and CLI-based SSH if supported).
If a feature is not supported on one platform (e.g., CLI SSH for Windows), clearly explain why and suggest alternatives.
Avoid language that implies one platform is easier or more supported than the other; instead, neutrally describe the requirements for each.
Consider reordering or parallelizing the documentation so that Linux and Windows instructions are presented side-by-side for each feature.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by referencing Windows directory paths (e.g., D:\home\site\wwwroot) before Linux equivalents, using Windows-style path separators in examples, and omitting explicit Linux/Bash command examples or Linux-specific instructions. The focus is on Windows conventions and tools, with limited mention of Linux environments or parity.

Recommendations:

Present both Windows and Linux directory paths together, or list Linux paths first where appropriate (e.g., '/home/site/wwwroot' before 'D:\home\site\wwwroot').
Include Linux/Bash command examples alongside Azure CLI, especially where file paths or manual steps are shown.
Use cross-platform path notation (e.g., '<project-root>/app_data/jobs/...') or provide both Windows (\) and Linux (/) path examples.
Explicitly mention differences or considerations for Linux-based App Service plans, including any variations in deployment directories or behaviors.
Add troubleshooting notes or caveats specific to Linux environments if applicable.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation demonstrates a Windows bias by primarily referencing Windows-centric workflows and tools (e.g., Visual Studio, right-click context menus), and omitting explicit Linux or cross-platform alternatives for key steps such as file creation, package installation, and deployment. Command-line or editor-agnostic instructions are not provided, and Linux-specific guidance is missing.

Recommendations:

For file creation and editing steps, provide equivalent CLI commands (e.g., using 'touch', 'nano', or 'vim') and/or instructions for popular cross-platform editors (e.g., VS Code) alongside Visual Studio instructions.
When referencing package installation, include explicit .NET CLI commands (e.g., 'dotnet add package Microsoft.SemanticKernel') in addition to NuGet/Visual Studio GUI steps.
Clarify that all steps can be performed on Linux, macOS, or Windows, and provide any OS-specific notes as needed (e.g., for environment variable configuration).
For deployment, mention cross-platform deployment options (e.g., using 'az webapp deploy', 'dotnet publish', or GitHub Actions) and not just portal-based workflows.
Where screenshots or UI navigation are referenced, provide alternative text-based instructions for users not on Windows or not using Visual Studio.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a mild Windows bias. In the prerequisites and quickstart links, 'windows' is specified first in tabbed instructions, and there is a lack of explicit Linux or cross-platform deployment examples. The guidance for environment variable setup and deployment references the Azure portal and Visual Studio, both of which are more commonly associated with Windows workflows. There are no explicit Linux shell or deployment examples, and no mention of Linux-specific tools or patterns, despite the 'linux-related-content' tag.

Recommendations:

Provide explicit Linux (and macOS) command-line examples for environment variable setup and deployment, such as using Bash or zsh.
Include instructions for deploying from Linux environments, such as using Azure CLI from a Linux terminal, or deploying via GitHub Actions or other cross-platform CI/CD tools.
When referencing quickstarts or sample apps, ensure that Linux tabs/examples are given equal prominence to Windows, or provide a neutral (cross-platform) default.
Mention and demonstrate use of Linux-native editors (e.g., VS Code on Linux, nano, vim) or terminal workflows where appropriate.
Clarify that all Python and Azure CLI commands are cross-platform unless otherwise noted, and avoid implying that Visual Studio is required for deployment.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ windows_first

Summary:

The documentation page demonstrates a Windows bias by exclusively providing PowerShell-based examples for per-app scaling, with no equivalent examples for Linux-native tools (such as Bash/CLI). The use of Azure PowerShell cmdlets is emphasized, and there is no mention of cross-platform alternatives like the Azure CLI. This may make it less accessible for Linux or macOS users who do not use PowerShell.

Recommendations:

Add equivalent Azure CLI (az) examples for all PowerShell commands to ensure Linux and macOS users can follow along easily.
Explicitly mention that per-app scaling can be configured using Azure CLI, and provide sample commands.
Consider providing Bash script examples where appropriate, or at least note cross-platform compatibility.
Reorganize sections so that cross-platform tools (Azure CLI, ARM templates) are presented before or alongside PowerShell examples, rather than PowerShell first.
Clarify in the introduction that all features are available regardless of OS, and link to cross-platform tooling documentation.

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 examples are always listed after CLI and are included in every relevant section. There are no explicit Linux shell or Bash script examples beyond the use of Azure CLI, and no mention of Linux-specific tools or patterns. Additionally, outbound IPv6 support is noted as being available only for Windows apps, with no Linux parity.

Recommendations:

Clarify that Azure CLI commands work cross-platform (Windows, macOS, Linux) and are the recommended approach for Linux users.
Explicitly state that PowerShell examples are primarily for Windows users, and consider providing Bash script equivalents for common tasks.
Where PowerShell is shown, consider also showing a Bash or shell script example for Linux users, especially for tasks involving parsing or automation.
For outbound IPv6 support, clarify the roadmap or alternatives for Linux users, or provide a link to track Linux support status.
In sections where only PowerShell and CLI are shown, add a note or example for Linux users if there are any OS-specific caveats or differences.
Review the ordering of examples to avoid implicit prioritization of Windows tools; consider presenting CLI (cross-platform) first, then PowerShell, then any OS-specific notes.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows-first bias by exclusively referencing Windows-style paths (e.g., D:\home), using Windows-centric terminology, and omitting Linux-specific examples or equivalents. Tools and folder structures are described only in the context of Windows environments, and there is no guidance for Linux-based App Service plans. The only mention of Linux is to state that the feature is unsupported for Linux containers, but there are no examples or instructions for Linux App Service environments.

Recommendations:

Provide parallel examples and explanations for Linux-based App Service plans, including Linux file paths and environment variables.
Clarify which features and instructions apply to Windows, Linux, or both, ideally with clear sections or callouts.
Include Linux-native tools or commands (e.g., using du or ls to check folder sizes) alongside Windows tools.
Mention and link to documentation for Linux equivalents or alternatives (such as App Cache for Linux) more prominently.
Avoid using only Windows paths (D:\home, D:\local) and instead provide Linux path equivalents (e.g., /home/site, /home/LogFiles) where appropriate.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates subtle Windows bias by providing detailed subnet/IP calculation examples specifically for Windows Containers, mentioning Windows Server Active Directory domain join as a non-supported feature, and referencing Kudu (a tool with a Windows-centric history) for environment variable inspection. While Linux is mentioned in the context of continuous deployment network dependencies, there is a lack of parity in example depth and troubleshooting guidance for Linux scenarios. No Linux-specific subnet/IP calculation examples or Linux-native tools are discussed.

Recommendations:

Add equivalent subnet/IP calculation examples for Linux containers and Linux App Service plans, including any unique considerations.
Provide Linux-specific troubleshooting steps and references to Linux-native tools (e.g., bash, curl, netcat) for network diagnostics.
Balance the mention of Kudu with references to Linux-native diagnostic environments (e.g., SSH, bash console in App Service for Linux).
Clarify any differences in environment variable access or behavior between Windows and Linux App Service environments.
Ensure that all feature limitations and configuration steps are equally documented for both Windows and Linux, including any Linux-specific caveats.

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 not available or documented for Linux. Windows-specific tools and log formats (e.g., W3C, Log Parser, .NET logging) are mentioned, while Linux equivalents or alternatives are not provided. Linux logging instructions are brief, and several logging features are either unavailable or not explained for Linux, leading to missing Linux examples.

Recommendations:

Clearly indicate which logging features are exclusive to Windows and which are available on Linux, and provide parity where possible.
Add equivalent Linux examples and instructions for all logging scenarios, or explicitly state if a feature is not supported on Linux.
Include Linux-friendly tools and log formats, and suggest open-source alternatives to Windows tools like Log Parser.
Provide more detailed guidance for Linux/container logging, including how to access, parse, and analyze logs.
Where features are not available on Linux, suggest workarounds or best practices for Linux users.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias by referencing Windows-specific tools (IIS, Procdump, SysInternals), focusing on .NET/ASP.NET examples, and highlighting PowerShell and DOS commands in the Kudu Console. There is a lack of Linux-specific troubleshooting guidance, and Linux-native tools or command-line examples are not mentioned. The Application Insights Profiler section links specifically to enabling the .NET Profiler for Windows, and the Kudu Console is described in terms of Windows shell commands. No parity is provided for Linux-based App Service environments.

Recommendations:

Include Linux-specific troubleshooting steps and examples, such as using Bash in the Kudu Console, and mention Linux-native diagnostic tools (e.g., strace, lsof, top).
Provide guidance for enabling and interpreting logs on Linux-based App Service plans, including differences from Windows (e.g., no IIS, different log file locations).
When referencing PowerShell or DOS commands, also provide equivalent Bash or Linux shell commands.
Link to documentation for Application Insights Profiler and diagnostic features as they apply to Linux-based App Service environments.
Clarify when features or tools are Windows-only and provide alternatives or workarounds for Linux users.
Add examples and guidance for troubleshooting Node.js, Python, Java, or other non-.NET apps, especially as they run on Linux App Service.

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 are typically associated with Windows-centric workflows. All examples and instructions use .NET (a historically Windows-first framework), and there is no mention of Linux-specific tooling, deployment, or terminal commands. The tutorial omits any Linux shell or non-Windows environment considerations, and does not provide parity for developers using Linux locally or alternative editors/IDEs.

Recommendations:

Explicitly mention that all commands and steps work on both Windows and Linux, or provide Linux-specific notes where differences exist.
Include examples of running the app and deploying from a native Linux terminal (e.g., bash), not just from Codespaces.
Reference Linux-native editors (e.g., VS Code on Linux, Vim, etc.) and clarify that .NET Core and Azure CLI are fully supported on Linux.
If any step is different on Linux (such as environment variable handling or file paths), provide those details.
Add a note or section for developers running the sample locally on Linux, including prerequisites (e.g., installing .NET SDK and Azure CLI on Ubuntu).
Ensure security best practices mention Linux-specific considerations (such as file permissions or SELinux/AppArmor if relevant).

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a mild Windows bias. In several sections, Windows-specific tools, settings, and commands are mentioned before their Linux equivalents or without Linux parity. For example, in the ReadyToRun section, Windows runtime identifiers and Visual Studio publishing instructions are detailed before Linux, and the Visual Studio workflow is described in more depth than Linux alternatives. Some CLI commands and configuration steps are shown for Windows first, and the use of Visual Studio (a Windows-centric tool) is emphasized in deployment and debugging sections. While Linux is mentioned and supported, Linux-specific examples and workflows are less prominent or are referenced as secondary options.

Recommendations:

Ensure that all CLI and configuration instructions are presented for both Windows and Linux, ideally side-by-side or with equal prominence.
Provide Linux-specific examples and workflows (e.g., using VS Code, Azure CLI, or other cross-platform tools) wherever Visual Studio or Windows PowerShell is mentioned.
When listing tools or deployment methods, alternate the order or present Linux and Windows options together, rather than defaulting to Windows first.
Expand on Linux container deployment and debugging workflows to match the detail provided for Windows/Visual Studio.
Where possible, include explicit Linux shell commands and terminal output, not just Azure CLI or Visual Studio instructions.
Audit for any references to Windows-only features or settings and clarify their Linux equivalents or note if not applicable.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation provides both Azure CLI and Azure PowerShell examples for managing access keys, but the PowerShell examples are detailed and prominent, and there is no explicit mention or example for Linux shell scripting or Bash outside of Azure CLI. The CLI examples are stated to run in Azure Cloud Shell (Bash), but there is a note that they must be modified to run in a Windows terminal, suggesting a Windows-first perspective. No Linux-specific tools or shell script examples are provided, and PowerShell is presented as a primary scripting method.

Recommendations:

Add explicit Bash or shell script examples for key management tasks, especially for scenarios where scripting is needed outside of Azure CLI.
Clarify that Azure CLI commands work natively on Linux, macOS, and Windows, and provide any necessary notes for cross-platform usage.
Balance the prominence of PowerShell and CLI examples by ensuring that Linux/Bash scripting is equally represented, especially for automation scenarios.
Where PowerShell scripts are provided, offer equivalent Bash scripts for users who may not use PowerShell.
Avoid language that implies Windows is the default or primary environment (e.g., 'You must modify it to run in a Windows terminal'), and instead provide parallel guidance for both Windows and Linux users.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation generally aims for cross-platform parity, but there are subtle signs of Windows bias. In command-line examples, both Bash and Windows CMD are provided, but Windows CMD is often listed second, which is good. However, there is no explicit mention of PowerShell, which is positive. Some terminology (e.g., 'command prompt') is Windows-centric, and there are no explicit Linux-specific troubleshooting steps or environment notes. The documentation does not provide Linux-specific examples or highlight differences in behavior between Windows and Linux environments, especially in areas like file paths, environment variables, or deployment nuances. The 'Java versions' table does list both Windows and Linux, but Windows is listed first. There is also a lack of explicit Linux tooling or troubleshooting guidance.

Recommendations:

When referencing terminals, use neutral terms like 'terminal' or 'shell' instead of 'command prompt', or explicitly mention both (e.g., 'terminal or command prompt').
Wherever Bash and CMD examples are given, consider listing Bash first to reflect the prevalence of Linux/macOS among Java developers.
Add Linux-specific notes or troubleshooting steps where relevant, especially for environment variables, file paths, and deployment behaviors.
If there are any differences in local development, deployment, or logging between Windows and Linux, explicitly document them.
Consider including a section or callout for Linux users, highlighting any OS-specific caveats or best practices.
Ensure that all screenshots, if any, are not Windows-only, or provide Linux equivalents.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation generally maintains good cross-platform parity, but there are subtle signs of Windows bias. In several places, Windows terminology ("command prompt") is used alongside "terminal" without explicit mention of Linux or macOS. The recommended development tools (Visual Studio Code, Azure Functions Core Tools) are cross-platform, but the documentation sometimes refers to 'command prompt' (a Windows term) and suggests remote build is recommended 'when developing Python apps on Windows', without giving equal emphasis to Linux/macOS workflows. There are also references to Windows-specific behaviors in the Python standard library section, and the folder structure examples use Windows-style command prompt code blocks (```cmd), which may be less familiar to Linux users.

Recommendations:

Explicitly mention Linux and macOS alongside Windows when referring to terminals or development environments (e.g., 'terminal (Linux/macOS) or command prompt (Windows)').
When recommending remote build for Windows users, also provide guidance for Linux/macOS users, including any platform-specific considerations.
Use neutral or platform-appropriate code block labels (e.g., 'shell' or 'bash' instead of 'cmd') for folder structure and command-line examples.
Where Windows-specific behaviors are described (such as in the Python standard library section), provide equivalent notes for Linux/macOS users.
Ensure that all instructions, especially for publishing and package management, are equally detailed for Linux/macOS as for Windows.
Consider adding explicit Linux/macOS command-line examples (e.g., using bash/zsh) where only generic or Windows-oriented instructions are given.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation displays some Windows bias, particularly in the Java section, where command examples are provided for Bash, PowerShell, and Cmd, with PowerShell and Cmd (Windows shells) given equal prominence to Bash. The use of 'command prompt' and 'PowerShell' is frequent, and Windows-specific tools and patterns (such as .cmd and PowerShell tabs) are included. However, the main workflow is generally cross-platform, and Linux tools like jq are mentioned in prerequisites. Still, Windows shells and terminology are often foregrounded or given equal weight, rather than Linux-first or Linux-equal treatment.

Recommendations:

In command examples, list Bash (Linux/macOS) first, followed by PowerShell and Cmd, to reflect the prevalence of Linux in cloud development.
Where possible, use neutral terms like 'terminal' instead of 'command prompt' or 'PowerShell', unless the example is truly Windows-specific.
For Java, consider providing a single cross-platform Maven command (with notes for quoting differences if needed), or clearly indicate which shell is most common for cloud developers.
Ensure that all shell-specific instructions are balanced and that Linux/macOS users are not required to adapt Windows-centric instructions.
Highlight Linux/macOS compatibility in prerequisites and throughout the workflow, especially for tools like Azure CLI and Azure Functions Core Tools.
Where Windows-specific tools or patterns are mentioned (e.g., .cmd, PowerShell), provide Linux/macOS equivalents or clarify when they are not needed.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation demonstrates a moderate Windows bias. Windows-specific plans and behaviors are often mentioned before Linux equivalents, and PowerShell examples are provided alongside (or before) CLI examples. Some features and settings are described as 'Windows only' without always providing equivalent Linux guidance. In several sections, Linux-specific instructions or parity are either missing or only briefly mentioned, and Windows tools (like Visual Studio and PowerShell) are referenced more prominently than Linux alternatives.

Recommendations:

Ensure that all examples and configuration instructions are provided for both Windows and Linux environments, with equal prominence.
When referencing tools like Visual Studio or PowerShell, also mention and provide examples for common Linux tools (e.g., VS Code, Bash, Azure CLI).
Avoid labeling features as 'Windows only' without clearly describing the Linux equivalent or explicitly stating the lack of parity.
Present cross-platform examples (CLI, Bash, PowerShell) side-by-side or in tabs, and avoid defaulting to Windows-first ordering.
Expand on Linux-specific deployment and configuration scenarios, especially where behaviors differ from Windows.
Audit for any missing Linux examples, especially in sections discussing storage configuration, scaling, and mounting file shares.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation page demonstrates a Windows bias by exclusively providing instructions and screenshots for Windows environments, particularly for managing SMB permissions. All examples for setting NTFS and share permissions use Windows tools (MMC, Windows Security tab), with no mention of Linux or cross-platform alternatives. There are no Linux or Samba client instructions for accessing or managing SMB shares, and Windows terminology and tools are referenced first and exclusively.

Recommendations:

Add instructions for managing SMB share and NTFS permissions from Linux clients, such as using smbclient, setfacl, or mount.cifs.
Include Linux/Samba client examples for connecting to and interacting with the SMB volume.
Provide parity in screenshots and walkthroughs for both Windows and Linux environments.
Reference cross-platform tools and clarify which steps are specific to Windows versus those that are platform-agnostic.
Mention any limitations or differences in SMB feature support between Windows and Linux clients.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page focuses exclusively on assessing ASP.NET web apps, implicitly assuming a Windows environment by referencing ASP.NET (which is historically Windows-centric) and providing no mention of Linux-based .NET apps, Linux tools, or cross-platform assessment workflows. All referenced tools and tutorials are tailored to Windows-centric migration scenarios, with no guidance for Linux users.

Recommendations:

Include explicit guidance and examples for assessing .NET web apps hosted on Linux, such as those running on .NET Core or ASP.NET Core on Linux servers.
Mention and link to any cross-platform or Linux-compatible assessment tools, if available.
Add a section or note clarifying support for Linux-based .NET apps and how the assessment process may differ.
Ensure referenced tutorials and best practices cover both Windows and Linux scenarios, or clearly indicate platform applicability.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation demonstrates a bias toward Windows by exclusively describing configuration steps through the Azure portal UI, which is most commonly accessed and depicted in a Windows environment. There are no CLI, PowerShell, or Linux shell examples, nor are there references to cross-platform command-line tools or automation approaches. This omission may disadvantage Linux users or those preferring non-GUI workflows.

Recommendations:

Add equivalent instructions using Azure CLI (az) commands for configuring GitHub authentication, which are cross-platform and suitable for Linux users.
Include examples for updating application settings and identity providers using command-line tools (e.g., Bash scripts, Azure CLI) alongside portal-based instructions.
Explicitly mention that the Azure portal is web-based and accessible from any OS, but provide parity for users who prefer or require CLI-based configuration.
Where secrets or settings are updated, show both portal and CLI-based approaches to ensure inclusivity for Linux and automation-focused users.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation demonstrates environment-specific configuration using ASP.NET Core and Azure App Configuration, but all examples and instructions assume a Windows-centric development environment. It references modifying 'launchSettings.json' (a Visual Studio/Windows convention) and does not mention or provide guidance for Linux or cross-platform development environments. There are no examples for setting environment variables or running the app in Linux shells or containers.

Recommendations:

Include instructions for setting environment variables in Linux/macOS shells (e.g., export ASPNETCORE_ENVIRONMENT=Production) alongside the launchSettings.json method.
Mention that 'launchSettings.json' is primarily used by Visual Studio and dotnet CLI on Windows, and provide alternatives for Linux users.
Add examples for running the application in Linux/macOS terminals, including how to set environment variables inline (e.g., ASPNETCORE_ENVIRONMENT=Development dotnet run).
Clarify that the instructions apply to all platforms and explicitly call out any platform-specific steps.
Consider including a section or note on running and configuring the app in Docker containers, which is a common cross-platform scenario.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation demonstrates a mild Windows bias by prioritizing Windows-specific guidance and tools. Windows is mentioned first in several contexts, and the installation instructions for Windows rely on the use of WSL (Windows Subsystem for Linux), which is a Windows-only technology. Additionally, Azure PowerShell is referenced alongside Azure CLI, but no Linux-native alternatives are highlighted. However, Linux installation and usage are covered, and most examples are cross-platform.

Recommendations:

Provide native Windows redis-cli installation instructions or clarify if WSL is the only supported method.
When listing methods to retrieve cache keys, present Azure CLI (cross-platform) before Azure PowerShell (Windows-centric), or clarify parity.
Explicitly mention that all redis-cli commands and examples work identically on Linux, macOS, and Windows (via WSL or otherwise).
If possible, link to or describe redis-cli binaries or installers for Windows without requiring WSL, or clarify the lack thereof.
Ensure that Linux and macOS are mentioned equally in all tool and usage sections, not just in installation.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation exhibits a mild Windows bias by linking exclusively to Windows-specific Azure portal documentation for proximity placement groups (PPGs) and by referencing Windows documentation paths before or instead of Linux equivalents. There are no explicit PowerShell examples or CLI commands, but the only direct example for creating a PPG points to a Windows-specific guide, and there is no mention of Linux or cross-platform alternatives.

Recommendations:

Provide links to both Windows and Linux (or cross-platform Azure CLI) documentation for tasks such as creating proximity placement groups.
When referencing Azure portal or command-line instructions, use neutral or cross-platform documentation paths (e.g., /azure/virtual-machines/proximity-placement-groups-portal instead of /azure/virtual-machines/windows/proximity-placement-groups-portal).
Explicitly mention that the guidance applies to both Windows and Linux SAP HANA deployments, or clarify any platform-specific considerations.
Include example commands or workflows using Azure CLI or ARM templates, which are platform-agnostic, alongside any portal-based instructions.

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation exhibits a 'windows_first' bias in the section describing the configuration file path. It mentions the Windows deployment path (C:\home\site\wwwroot) first and provides a relative path example for Windows, while the Linux path is only mentioned later and as a note. There are no explicit Linux command-line or tool examples, and the documentation assumes familiarity with Windows file paths and conventions.

Recommendations:

Present Linux and Windows instructions/examples side by side or in parallel sections to ensure parity.
When mentioning file paths, provide both Windows and Linux examples together (e.g., 'C:\home\site\wwwroot\auth.json' for Windows and '/home/site/wwwroot/auth.json' for Linux).
Clarify any platform-specific limitations or differences in the main instruction steps, not just in notes.
Include Linux-specific deployment or configuration tips where relevant, such as using Linux shell commands or tools.
Avoid assuming the reader is deploying to Windows by default; use neutral language or explicitly state when instructions differ by platform.

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation page lists .NET and ASP.NET Core providers (primarily Windows-centric technologies) first in the table of configuration provider libraries, with their samples and release notes appearing before Java, Python, JavaScript, and Go equivalents. There are no explicit Windows-only tools or PowerShell examples, nor are Linux or cross-platform command-line examples present. However, the ordering and emphasis on .NET/Windows technologies may subtly suggest a Windows-first bias.

Recommendations:

Reorder the provider libraries table to group by language family or present cross-platform options (e.g., Java, Python, Go) before or alongside .NET/Windows-centric options.
Explicitly mention the cross-platform compatibility of each provider, especially for .NET Standard and .NET Core, to clarify that they are not Windows-only.
Add a note or section highlighting Linux and macOS support, and provide links to Linux/macOS-specific samples or documentation where relevant.
Ensure that future documentation includes examples and troubleshooting steps for Linux environments, not just Windows or Visual Studio workflows.

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation presents environment variable setup instructions in the order of Windows CMD, PowerShell, and then macOS/Linux, which prioritizes Windows users. However, all platforms are covered and there are no missing Linux examples or exclusive use of Windows tools.

Recommendations:

Present environment variable setup instructions in parallel (side-by-side table or grouped subsections) rather than listing Windows first.
Consider starting with a cross-platform example (e.g., using dotenv or a Node.js script) before platform-specific instructions.
Explicitly state that all major platforms are supported and provide equal prominence to Linux/macOS instructions.
Where possible, use platform-agnostic language and tools in code and instructions.

Create pull request

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