Scan Details - Linux-first Docs for Azure

362

Pages Scanned

46

Pages Flagged

362

Changed Pages

12.7%

% Pages Flagged

Live Progress

🔴 Connecting...

0%

Phase: discovery

Processing: Initializing...

Activity Feed

00:01:01 Scan started

Scan Information

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

Finished At: In Progress

Status: in_progress

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

Current Phase: discovery

Problematic Pages

Bias Types:

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ windows_first

Summary:

The documentation page demonstrates a Windows bias by only referencing Windows-centric tools and workflows (such as the Azure portal and Visual Studio Code), omitting Linux-specific instructions or alternatives. There are no command-line examples for Linux (e.g., Bash, curl), and the only development tool mentioned is Visual Studio Code, which, while cross-platform, is often associated with Windows in Microsoft documentation. No mention is made of Linux-native tools or how to perform tasks outside the Azure portal.

Recommendations:

Include command-line examples using Bash and curl for interacting with the MCP server endpoint, in addition to or instead of portal-only instructions.
Explicitly mention that Visual Studio Code is available on Linux and provide setup instructions for Linux users.
Provide alternative instructions for testing the MCP server using Linux-native tools (e.g., httpie, curl, or Postman on Linux).
Add screenshots or walkthroughs using a Linux environment where relevant.
Ensure parity in tool recommendations by listing both Windows and Linux options for each step, especially for testing and development.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation demonstrates a moderate Windows bias. In all command-line example sections, Azure PowerShell is presented before Azure CLI, and PowerShell cmdlets are referenced multiple times (including for status checks, even in the CLI section). There are no explicit Linux-specific examples or mentions of Linux-native tools or shell environments. The documentation assumes familiarity with PowerShell and the Azure Portal, both of which are more commonly used by Windows administrators. There are no Bash or Linux shell script examples, and the CLI output references PowerShell cmdlets for status checks, which may confuse Linux users.

Recommendations:

Present Azure CLI examples before or alongside PowerShell examples to avoid Windows-first ordering.
In CLI sections, use only Azure CLI commands for all steps, including status checks (replace 'Get-AzProviderFeature' with 'az feature show' or similar).
Explicitly mention that Azure CLI commands work cross-platform (Linux, macOS, Windows) and provide Bash-friendly syntax where appropriate.
Add examples or notes for Linux users, such as running Azure CLI in Bash or using shell scripting for automation.
Avoid referencing PowerShell cmdlets in CLI sections; keep each section self-contained and relevant to the tool/environment.
Consider including a table or section summarizing parity between PowerShell and CLI commands, clarifying cross-platform support.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows/Powershell bias by exclusively referencing Azure PowerShell scripts and cmdlets for migration and preview registration/unregistration tasks. There are no Bash, Linux shell, or cross-platform CLI examples provided, despite Azure CLI being cross-platform. The only automation tooling mentioned is PowerShell, and the tutorial link also points to a PowerShell-based walkthrough. No Linux-specific or neutral (Bash) examples are given.

Recommendations:

Provide equivalent Azure CLI (bash/shell) command examples alongside PowerShell commands for all tasks, especially for migration and preview registration/unregistration.
Include links to tutorials or walkthroughs that use Azure CLI in Bash or cross-platform environments, not just PowerShell.
When referencing scripts or automation, mention both PowerShell and Bash/CLI options, or clarify when a task is only possible in PowerShell.
Ensure that documentation language and examples are inclusive of both Windows and Linux users by alternating or combining examples where appropriate.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation demonstrates a bias toward Windows by providing only PowerShell commands (specifically Remove-AzResourceGroup) for resource cleanup, referencing IIS (a Windows web server) as the default backend and validation method, and omitting equivalent Linux/CLI examples for these steps. No Linux-native tools or instructions are provided for validation or resource management.

Recommendations:

Provide Azure CLI examples alongside PowerShell for resource group deletion (e.g., az group delete --name <group-name>).
Include instructions for deploying and validating with a Linux-based web server (such as Nginx or Apache) on the backend VMs, or clarify how to adapt the template for Linux VMs.
Offer browser-based validation instructions that are OS-agnostic, or explicitly mention that the validation step works regardless of backend OS.
Where possible, avoid assuming the use of Windows-specific tools (like IIS) and provide parity for Linux users in both deployment and validation steps.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation page demonstrates a strong Windows bias: all migration tools and examples focus exclusively on migrating from Windows (IIS) environments, with repeated emphasis on PowerShell scripts and Windows-specific tools. There is no mention of Linux-based .NET hosting environments, nor are there migration paths, tools, or examples for Linux servers. The documentation assumes the source environment is always Windows/IIS, omitting Linux scenarios entirely.

Recommendations:

Add guidance and tooling for migrating .NET apps hosted on Linux (e.g., Apache, Nginx, Kestrel) to Azure App Service.
Include Linux-based migration tool options or scripts (such as Bash or cross-platform .NET CLI commands) alongside PowerShell examples.
Explicitly mention support (or lack thereof) for Linux source environments, and provide parity in documentation structure and examples.
Highlight any differences or additional considerations when migrating from Linux environments.
Ensure that documentation tables and feature lists include Linux scenarios where applicable, or clearly state if only Windows is supported.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation page demonstrates a mild Windows bias. It references Windows-specific tools (such as web.config and iisnode) without providing equivalent Linux alternatives or explanations. In the Node.js section, iisnode settings are mentioned as a configuration point, but there is no mention of Linux-native process managers or configuration files. The auto-healing feature is described as being configured via web.config, which is a Windows/IIS-centric approach, with no mention of Linux equivalents. While there is a brief mention of PM2 for Node.js on Linux, the overall pattern is to present Windows tools and patterns first or exclusively.

Recommendations:

For features like auto-healing, provide Linux-native configuration instructions (e.g., using application settings, environment variables, or startup scripts) alongside or instead of web.config.
When referencing iisnode or web.config for Node.js apps, also mention Linux-native process managers (such as PM2 or systemd) and their configuration approaches.
Ensure that all examples and configuration guidance are available for both Windows and Linux App Service environments, and present them in parallel or with clear distinctions.
Where possible, avoid assuming the use of Windows/IIS-specific tools as the default; clarify when guidance is platform-specific.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation demonstrates a moderate Windows bias by presenting Windows-related information and tools before their Linux equivalents. In the 'Premium V3 availability' section, the Windows SKU availability command is listed before the Linux one. The automation section provides both Azure CLI and Azure PowerShell examples, but PowerShell is a Windows-centric tool, and no Linux shell scripting (e.g., Bash) examples are given. The use of the Azure portal UI, which is platform-agnostic but often associated with Windows workflows, is emphasized throughout. There are no explicit Linux shell or scripting examples beyond the Azure CLI, and no mention of Linux-specific considerations or tools.

Recommendations:

Present Linux and Windows options in parallel or alternate their order to avoid always listing Windows first.
Include Bash or shell script examples for automation, especially for Linux users.
Explicitly mention that Azure CLI commands work cross-platform and can be run on Linux, macOS, and Windows.
If referencing PowerShell, clarify that PowerShell Core is cross-platform, or provide equivalent Bash commands where possible.
Highlight any Linux-specific considerations or differences when using Premium V3, if applicable.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation shows a moderate Windows bias. Windows is mentioned first in availability, and PowerShell scripting is presented as a primary automation method alongside Azure CLI. There are no Linux shell (bash) or cross-platform scripting examples, and the portal instructions are Windows-centric. Linux is only referenced in the context of SKU availability, not in automation or deployment workflows.

Recommendations:

Provide bash shell scripting examples for Linux users alongside Azure PowerShell examples.
When listing availability or instructions, present Windows and Linux options in parallel, not with Windows first.
Clarify that Azure CLI is cross-platform and can be used from Linux, macOS, and Windows.
Include screenshots or instructions for the Azure portal that are not Windows-specific (e.g., avoid showing only Windows UI elements or terminology).
Explicitly mention Linux container scenarios in automation and deployment sections.
Add a table or section summarizing differences and steps for both Windows and Linux App Service plans.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a moderate Windows bias. Windows instructions, tools, and troubleshooting steps are often presented first or exclusively. PowerShell and Windows-specific tools are referenced without always providing Linux equivalents. The GUI for Hybrid Connection Manager is only available on Windows, and while Linux CLI instructions are present, some troubleshooting and testing steps (e.g., Test-NetConnection) are only shown for Windows/PowerShell. Linux users are sometimes directed to use generic tools (like nslookup or curl) but not always given parity in examples or troubleshooting steps.

Recommendations:

For every PowerShell or Windows-specific command (e.g., Test-NetConnection), provide the Linux equivalent (e.g., nc or telnet for TCP connectivity tests).
When listing installation or usage instructions, alternate the order or present both Windows and Linux instructions side-by-side to avoid a 'Windows-first' impression.
Where GUI tools are only available for Windows, clearly state this and provide enhanced CLI or alternative tooling guidance for Linux users.
Expand troubleshooting sections to include Linux-native commands and workflows (e.g., systemctl for service management, journalctl/logs for diagnostics).
Ensure that all example commands, especially for connectivity and diagnostics, are shown for both platforms.
Consider adding a dedicated Linux troubleshooting section or quick reference for common tasks.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation demonstrates a Windows bias by providing PowerShell scripts as the only automation example for identifying impacted Azure Traffic Manager endpoints, without offering Bash, Azure CLI, or cross-platform alternatives. References to 'open PowerShell' and script execution instructions are Windows-centric. There is no mention of Linux/macOS-compatible approaches, and PowerShell is presented as the default or only automation tool for certain tasks.

Recommendations:

Provide equivalent Bash or Azure CLI scripts for all PowerShell examples, especially for resource discovery and automation tasks.
Explicitly mention that PowerShell Core is cross-platform if PowerShell must be used, and provide instructions for Linux/macOS environments.
When referencing scripts, include both Windows (PowerShell) and Linux/macOS (Bash/CLI) usage instructions, or clarify if the script is cross-platform.
Avoid language such as 'open PowerShell' without also mentioning terminal or shell for non-Windows users.
Where possible, use Azure CLI examples as the primary automation method, as it is natively cross-platform.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation focuses exclusively on discovering ASP.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, such as .NET apps running on Apache, Nginx, or Kestrel on Linux. All examples and references are tailored to Windows tools and patterns, with no Linux equivalents provided.

Recommendations:

Include information about discovering .NET web apps hosted on Linux servers, such as those running on Apache, Nginx, or Kestrel.
Provide examples and guidance for Linux-based environments, including any Azure Migrate capabilities or limitations for Linux-hosted .NET apps.
Mention Linux discovery tools or processes where applicable, and ensure parity in documentation structure and detail.
Clarify in the introduction if the discovery feature is limited to Windows/IIS, or explicitly state support for Linux if available.

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 with iisnode. All configuration examples, troubleshooting steps, and tool references are tailored to Windows environments (e.g., node.exe, web.config, iisnode, named pipes, Win32 error codes, Kudu CMD/PowerShell). There are no Linux equivalents, examples, or guidance provided, and Linux-specific tools or deployment patterns are not mentioned.

Recommendations:

Add a parallel section or separate guide for Node.js applications running on Azure App Service Linux, covering configuration, deployment, and troubleshooting steps relevant to Linux environments.
Provide Linux-specific examples (e.g., using environment variables, PM2, NGINX/Apache, systemd) alongside or before Windows/iisnode examples.
Reference Linux tools and patterns (such as log file locations, process management, and debugging techniques) where appropriate.
Avoid assuming the use of Windows-only features (like web.config, named pipes, Win32 error codes) without offering Linux alternatives or clarifying that these are Windows-specific.
Include screenshots and walkthroughs for the Azure portal and Kudu/SSH experiences as they appear for Linux-based App Service plans.
Clearly indicate at the top of the document that the content is Windows-specific, and provide a link to Linux-focused documentation if available.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a mild Windows bias. While most command-line examples use the cross-platform Azure CLI, the only graphical tool mentioned for uploading files and generating SAS tokens is Azure Storage Explorer, and the link for generating SAS tokens specifically references the Windows tab. There are no Linux-specific instructions or examples for uploading files or generating SAS tokens, nor are alternative Linux-friendly tools or methods (such as azcopy or CLI-based SAS generation) mentioned. The documentation assumes the use of graphical tools more common on Windows, and does not provide parity for Linux users.

Recommendations:

Include instructions and examples for uploading files and generating SAS tokens using cross-platform CLI tools such as azcopy or Azure CLI.
When referencing Azure Storage Explorer, clarify its cross-platform availability and provide instructions for Linux/macOS users, or avoid linking specifically to the Windows tab.
Add explicit Linux/macOS command-line examples for all steps currently described only with GUI tools.
Consider mentioning alternative open-source or native Linux tools where appropriate.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation page demonstrates a clear Windows bias. It exclusively references Windows-based deployment and management tools (such as Visual Studio, Kudu, CMD, and PowerShell), and all file paths and runtime details are specific to Windows environments. There are no examples or instructions for Linux-based App Service environments, nor are Linux command-line tools or patterns mentioned. The documentation assumes the use of Windows App Service instances and omits Linux parity in both configuration and troubleshooting steps.

Recommendations:

Add equivalent instructions and examples for Linux-based App Service environments, including how to check .NET runtime versions and access diagnostic tools.
Include Linux shell (bash) commands and file paths where appropriate, alongside Windows examples.
Mention and demonstrate how to use cross-platform tools (such as Azure CLI) in both Windows and Linux contexts.
Clarify which steps or features are Windows-only and provide links or guidance for Linux users.
Provide parity in troubleshooting and diagnostic guidance for Linux-hosted ASP.NET apps, including log access and environment variable management.

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 more detailed and prescriptive, with step-by-step PowerShell scripts and explicit use of Windows-specific tools and paths. The Windows approach is described with more automation (PowerShell, .cmd files), while the Linux approach is more manual (shell scripts, apk, xsltproc). Windows-specific tools (PowerShell, .cmd) are featured prominently, and the Windows section appears before the Linux section in some places. However, both platforms are covered and Linux examples are present.

Recommendations:

Balance the level of detail: Expand the Linux section to provide equally detailed, step-by-step instructions, including example shell scripts that automate the process as thoroughly as the Windows PowerShell example.
Parity in automation: Provide a ready-to-use Bash script for Linux that mirrors the automation provided by the Windows PowerShell script, including checks for idempotency and error handling.
Tool parity: Where possible, suggest cross-platform tools or provide equivalent Linux-native commands/scripts for every Windows-specific tool or pattern (e.g., use Bash scripts instead of only PowerShell).
Order of presentation: Consider presenting Linux and Windows instructions in parallel or in the same order throughout the documentation to avoid the perception of Windows-first bias.
Clarify platform differences: Explicitly call out any differences in capabilities or limitations between Linux and Windows, and provide workarounds or alternatives for Linux where needed.

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 browser SSH access before Linux container details and CLI-based SSH access. The Windows section lacks parity with Linux, as it does not provide any command-line or PowerShell examples for SSH access, nor does it mention Windows-native tools or alternatives. Conversely, the Linux section provides detailed Azure CLI and SSH command examples, but there is no equivalent for Windows containers. This creates an imbalance in guidance and may leave Windows users without clear instructions for non-browser SSH access.

Recommendations:

Provide equivalent command-line (e.g., PowerShell) or Azure CLI instructions for opening SSH sessions to Windows containers, if supported.
If SSH via CLI is not supported for Windows containers, explicitly state this limitation and suggest alternative remote management options for Windows containers.
Include references to Windows-native SSH clients or tools (such as PowerShell's SSH capabilities or PuTTY) where appropriate.
Ensure that both Windows and Linux sections have comparable depth and clarity in their instructions, examples, and tool recommendations.
Consider reordering or parallelizing the presentation so that Linux and Windows instructions are given equal prominence and structure.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by referencing Windows file paths (e.g., D:\home\site\wwwroot) before Linux equivalents, describing deployment behaviors primarily in terms of Windows directory structures, and omitting explicit Linux/macOS command-line examples or file path conventions. The instructions and troubleshooting sections focus on Windows patterns, with only brief mentions of Linux, and do not provide parity in examples or guidance for Linux users.

Recommendations:

Provide Linux/macOS-specific examples and file paths alongside Windows ones, ensuring both are equally visible and explained.
When describing deployment directories, always mention both Windows (D:\home\...) and Linux (/home/...) paths together, not just as an afterthought.
Include sample commands for Linux/macOS shells (e.g., bash) where relevant, especially for file operations or troubleshooting.
Explicitly state any differences in behavior or requirements between Windows and Linux App Service environments.
Add troubleshooting tips and notes that are relevant to Linux users, not just Windows.
Ensure that all included code snippets, especially those involving file paths or system operations, have Linux equivalents.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a moderate Windows bias, especially in the .NET section, where Windows tools (Visual Studio, PowerShell) are listed before cross-platform or Linux-native options. Some quickstart and tutorial links default to Windows or PowerShell tabs, and Windows-specific tools are mentioned more prominently than their Linux equivalents. In contrast, Linux and CLI options are less emphasized or appear after Windows options. Other stacks (Java, Node.js, PHP) show better Linux parity, but the 'Next step' call-to-action also defaults to an ASP.NET (Windows-centric) example.

Recommendations:

Ensure that for every Windows/Powershell example or tool, an equivalent Linux/Bash/Azure CLI example is provided and given equal prominence.
In tables and lists, alternate the order of Windows and Linux tools, or group them together under neutral headings (e.g., 'Command line (Windows, Linux)').
Avoid defaulting to Windows tabs or PowerShell in quickstart/tutorial links; use neutral or platform-agnostic defaults, or provide clear tab choices.
Add explicit Linux/CLI examples for .NET where missing, especially for creation and deployment steps.
Balance the 'Next step' call-to-action by rotating or randomizing the stack, or providing a choice of language/platform.
Review all sections for implicit prioritization of Windows tools and ensure Linux users receive equal guidance and visibility.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation demonstrates a Windows bias by prioritizing Windows/Visual Studio workflows (e.g., right-clicking folders, using Visual Studio's NuGet package manager) and omitting explicit Linux or cross-platform command-line examples for key steps such as file creation, package installation, and deployment. There are no Linux-specific instructions or terminal/CLI commands for common developer tasks, and the documentation assumes a GUI-based workflow typical of Windows environments.

Recommendations:

Provide equivalent Linux (and macOS) instructions for file creation and project navigation, using CLI commands (e.g., 'touch', 'mkdir', 'nano', or 'code').
Include .NET CLI commands for package installation (e.g., 'dotnet add package Microsoft.SemanticKernel') alongside or before Visual Studio/NuGet GUI instructions.
Offer deployment instructions using Azure CLI or GitHub Actions, not just portal-based workflows.
Explicitly mention cross-platform compatibility and provide examples for both Windows and Linux environments where relevant.
Avoid assuming the use of Visual Studio or Windows-specific UI patterns; highlight VS Code or JetBrains Rider as alternatives.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ windows_first

Summary:

The documentation page demonstrates a strong Windows bias by providing only PowerShell examples for per-app scaling, with no equivalent examples for Linux-native tools (such as Azure CLI or Bash scripting). The use of PowerShell cmdlets (New-AzAppServicePlan, Set-AzAppServicePlan, Get-AzWebApp, Set-AzWebApp) is exclusive, and there is no mention of Linux or cross-platform workflows. ARM template examples are platform-neutral, but all imperative (command-line) guidance is Windows-centric.

Recommendations:

Add equivalent Azure CLI examples for all PowerShell commands, showing how to enable per-app scaling and configure number of workers using az appservice plan and az webapp commands.
Include Bash script snippets for Linux users where appropriate.
When introducing command-line instructions, present Azure CLI (cross-platform) examples before or alongside PowerShell examples.
Explicitly mention that PowerShell examples are for Windows users and provide guidance for Linux/macOS users.
Review related content and links to ensure Linux and cross-platform tooling is represented.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation demonstrates a moderate Windows bias. While Azure CLI (cross-platform) examples are present and often listed first, PowerShell commands (specific to Windows) are also provided in parallel, but there are no explicit Linux shell or Bash script examples beyond the CLI. The documentation references features (such as outbound IPv6 support) as being available only for Windows apps, with no Linux parity or roadmap. There are no Linux-specific troubleshooting or tool references, and the only shell command shown outside of Azure CLI is 'nslookup', which is cross-platform but not contextualized for Linux users. The documentation does not mention or address differences in experience for Linux-hosted App Service apps except to note missing features.

Recommendations:

Where PowerShell examples are provided, also include equivalent Bash or shell script examples (where applicable), especially for common tasks like querying properties with Azure CLI.
Explicitly note when features (such as outbound IPv6 support) are Windows-only, and provide a roadmap or workaround for Linux users if possible.
Add troubleshooting tips or notes for Linux users, such as differences in DNS tools or command syntax (e.g., using 'dig' as an alternative to 'nslookup').
Ensure that all CLI examples are tested and presented in a way that works seamlessly on both Windows and Linux terminals.
Where screenshots or portal instructions are given, clarify that the experience is the same or note any differences for Linux-hosted apps.
Consider including a section or callout specifically addressing Linux-hosted App Service scenarios, especially where feature parity is lacking.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page exhibits a Windows-first bias. All file paths and folder references use Windows-style paths (e.g., D:\home), and there is no mention of equivalent Linux paths or behaviors. The only tool mentioned for checking disk usage is 'Azure Web Apps Disk Usage', with no Linux-native alternatives. The documentation refers to Kudu/SCM, which is more closely associated with Windows-based App Service environments, and does not provide Linux-specific instructions or examples. There are no Linux shell or command-line examples, and Linux-specific behaviors or caveats are not addressed, except for a brief note that the feature is not supported in Linux containers.

Recommendations:

Add Linux-specific examples and clarify file paths for Linux-based App Service environments (e.g., /home/site/wwwroot instead of D:\home\site).
Mention Linux-native tools or commands (such as 'du' or 'ls') for checking disk usage and folder sizes.
Provide parity in instructions for both Windows and Linux App Service environments, including any differences in behavior or configuration.
Explicitly state any differences in how local cache works (or does not work) on Linux App Service plans, and provide links to relevant Linux documentation.
Where features are unsupported on Linux, suggest alternative approaches or workarounds for Linux users.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a mild Windows bias. Windows-specific features and limitations (e.g., Windows Containers subnet sizing, Windows Server Active Directory, NetBIOS) are discussed in detail, while Linux-specific scenarios are only briefly mentioned (e.g., a single note about Linux continuous deployment network dependencies). There are no Linux-specific configuration examples, troubleshooting steps, or parity in coverage for Linux container nuances. Windows terminology and tools (e.g., Kudu console, Windows Containers) are referenced without Linux equivalents or alternatives.

Recommendations:

Add Linux-specific examples and scenarios, such as subnet sizing for Linux containers, and clarify any differences in behavior or requirements.
Include Linux-native tools or references (e.g., SSH, Bash, Linux environment variables) alongside or in place of Windows-centric tools like Kudu.
Provide troubleshooting steps and configuration guidance that address common Linux deployment patterns (e.g., Docker Compose, Linux filesystem mounts, SELinux/AppArmor considerations).
Ensure that when platform-specific limitations or features are discussed (e.g., Windows Containers), equivalent Linux information is provided or explicitly state if not applicable.
Balance the order of presentation so that Linux and Windows are given equal prominence, or group platform-specific content under clearly labeled sections.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows-first bias by providing more detailed instructions, features, and examples for Windows App Service apps compared to Linux. Several logging types (web server logging, detailed error messages, failed request tracing) are documented only for Windows, with no Linux equivalents or alternatives described. Windows-specific tools and file paths are mentioned (e.g., Log Parser, D:\home\LogFiles), while Linux paths and tools are less emphasized or omitted. There are also sections where only .NET (Windows) logging to blob storage is supported, with other languages/platforms (often used on Linux) excluded or requiring code changes.

Recommendations:

Provide equivalent, step-by-step instructions for enabling web server logging, detailed error messages, and failed request tracing on Linux App Service (or clearly state if these features are unavailable).
Include Linux-specific file paths and examples (e.g., /home/LogFiles) alongside Windows paths in all relevant sections.
Mention Linux-compatible tools for viewing and parsing logs (e.g., less, tail, grep, jq) in addition to or instead of Windows tools like Log Parser.
Clarify feature parity and limitations for Linux and container-based App Service plans, and offer workarounds or alternatives where features are missing.
Expand code examples to include common Linux-targeted languages and frameworks (Node.js, Python, Java) with logging best practices for App Service.
Where a feature is Windows-only, provide a clear note and suggest alternative approaches for Linux users.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by referencing Windows-specific tools (IIS, Procdump, web.config), focusing on PowerShell for management, and linking to Windows-centric resources. There is a lack of Linux-specific examples, tools, or guidance, and the documentation implicitly assumes a Windows-based App Service environment.

Recommendations:

Provide equivalent Linux troubleshooting steps and examples, such as using SSH, Bash, or Linux-native diagnostic tools.
Mention Linux App Service differences, such as the absence of IIS and the use of different logging mechanisms.
Include Linux-specific tools (e.g., strace, lsof, top) for diagnostics and profiling.
Offer examples for managing and restarting apps using Azure CLI and Bash, not just PowerShell.
Clarify when a feature or tool is Windows-only, and provide alternatives for Linux-based App Service.
Update links and references to include Linux documentation and blog posts where available.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation shows subtle Windows bias by prioritizing Windows-centric tools and workflows, such as the Azure Portal UI (which is most commonly used on Windows), Visual Studio Code (with screenshots and instructions), and .NET/NUnit examples. There is a lack of explicit Linux/macOS terminal examples, and no mention of platform-specific differences or parity. The CLI instructions are generic, but the focus on Visual Studio Code and .NET/NUnit (both more common in Windows environments) without parallel Linux/macOS guidance or screenshots may leave Linux users underserved.

Recommendations:

Add explicit Linux/macOS terminal examples and clarify that all CLI commands work cross-platform.
Include screenshots or instructions for running Playwright tests from Linux/macOS terminals, not just Visual Studio Code or Azure Portal.
Mention any platform-specific prerequisites or differences (e.g., environment variable syntax differences between Windows and Unix shells).
Provide parity in .NET/NUnit and Node.js/Playwright examples for both Windows and Linux environments.
Clarify that Visual Studio Code is cross-platform, and optionally include screenshots from Linux/macOS versions.
Where PowerShell or Windows-specific commands are shown, also provide bash/zsh equivalents.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation demonstrates a moderate Windows bias. Windows-specific concepts (such as registry keys, Windows services, and file paths) are often described in more detail or appear first. Several examples, especially in the alerting/query section, use Windows file paths and registry keys without equivalent Linux examples. The registry monitoring section is entirely Windows-focused, and alerting scenarios prioritize Windows paths and services. While Linux is mentioned and supported, Linux-specific examples and explanations are less detailed or absent, and Windows terminology/tools (like PowerShell and Windows registry) are more prominent.

Recommendations:

Provide Linux-specific examples alongside Windows ones, especially in sections covering queries, alerting, and configuration.
Expand the registry monitoring section to discuss Linux equivalents, such as monitoring configuration files or system directories.
Balance the order of presentation so that Linux and Windows are given equal prominence (e.g., alternate which OS is described first in tables and examples).
Include Linux daemon/service monitoring examples with similar detail as Windows services.
Offer Linux-specific troubleshooting tips and limitations, not just Windows-focused ones.
Where PowerShell or Windows command-line tools are referenced, provide equivalent Bash or Linux shell commands.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation demonstrates a mild Windows bias in the 'Run the application' section, where Windows command prompt and PowerShell instructions are presented before Linux/macOS equivalents. Both 'setx' (Windows tool) and PowerShell are mentioned explicitly, while Linux/macOS only receives a single bash example. There are no missing Linux examples, but the ordering and explicit mention of Windows-specific tools and shells indicate a subtle preference for Windows environments.

Recommendations:

Present Linux/macOS and Windows instructions in parallel tabbed sections, or alternate which platform appears first to avoid implicit prioritization.
Use generic shell commands (e.g., 'export') first, with platform-specific notes as needed.
Minimize the use of Windows-specific tools like 'setx' unless absolutely necessary, and provide context for when each method is appropriate.
Explicitly state that all examples are cross-platform unless otherwise noted, and ensure parity in detail and explanation for each OS.
Consider adding a table or tabs for environment variable setup, with clear labels for 'Windows CMD', 'PowerShell', and 'Linux/macOS Bash' to reinforce equal support.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation page demonstrates a moderate Windows bias. PowerShell is presented as a primary automation tool alongside Azure CLI, with PowerShell examples consistently given before Azure CLI examples. There are no Linux-specific shell or scripting examples (e.g., Bash), and the documentation refers to Windows-centric tools and patterns (PowerShell cmdlets) without mentioning Linux-native alternatives. While Azure CLI is cross-platform, the absence of explicit Linux/Bash examples and the prioritization of PowerShell may make Linux users feel secondary.

Recommendations:

Add explicit Bash shell examples for all CLI commands, showing how to run them in a typical Linux environment.
When listing automation options, mention Bash scripting and Linux shell environments alongside PowerShell.
Alternate the order of PowerShell and CLI examples, or present them in parallel tabs, to avoid always putting Windows/PowerShell first.
Include notes or links for Linux users regarding installation and usage of Azure CLI and any relevant differences.
Where possible, provide examples using native Linux tools (e.g., curl for REST API calls) in addition to PowerShell and Azure CLI.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a mild Windows bias. While it does mention both Windows and Linux in several places, Windows-specific tools, patterns, and configuration steps are often mentioned first or in more detail. Some examples and instructions are Windows-centric (e.g., PowerShell, Visual Studio), and Linux equivalents are less prominent or missing. Azure CLI is included, but PowerShell is also highlighted as a primary method. In performance and deployment sections, Windows is often listed before Linux, and some ReadyToRun and debugging instructions are more detailed for Windows. Linux-specific nuances are not always equally explained.

Recommendations:

Ensure all command-line examples are provided for both Windows (PowerShell/CMD) and Linux (Bash), with clear tabs or sections for each.
When listing tools or deployment methods (e.g., Visual Studio, PowerShell), mention cross-platform options (like VS Code, Azure CLI) first or equally.
In performance and deployment sections, present Windows and Linux instructions in parallel, with equal detail and prominence.
Add Linux-specific examples and troubleshooting steps, especially for advanced scenarios like ReadyToRun, debugging, and deployment.
Review all references to Windows tools (e.g., PowerShell) and ensure Linux alternatives are provided and easy to find.
Where possible, use Azure CLI as the default for scripting/deployment, as it is cross-platform, and supplement with PowerShell only as an alternative.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a mild Windows bias. It assumes the use of Visual Studio Code and the Azurite storage emulator, both of which are cross-platform, but the instructions for starting Azurite ('Azurite: Start' in VS Code) and running/debugging the function app ('F5', 'Ctrl+C') are presented in a way that aligns more closely with Windows workflows. There are no explicit Linux/macOS terminal commands or alternative instructions for starting Azurite or running the function app outside of VS Code. Additionally, there are no references to Linux-specific tools or shell commands, and the documentation does not mention or show parity for Linux users in steps that could be performed via CLI or terminal, such as managing local.settings.json or starting/stopping the emulator. Powershell is included as a language pivot, but not favored in the main instructions.

Recommendations:

Include explicit instructions or notes for Linux/macOS users, such as how to start Azurite from the terminal (e.g., 'npx azurite' or 'azurite' command) and how to run/debug the function app using the Azure Functions Core Tools CLI.
When referencing keyboard shortcuts (e.g., F5, Ctrl+C), clarify if these are cross-platform or provide alternatives for macOS/Linux (e.g., Cmd+F5, etc.).
Add examples or notes for editing configuration files (like local.settings.json) using common Linux/macOS editors (e.g., nano, vim) or command-line tools.
Where possible, provide CLI commands (bash/zsh) for steps that can be performed outside of Visual Studio Code, such as installing dependencies or running the function locally.
Explicitly state that all tools and steps are cross-platform, and link to platform-specific installation or usage guides for Azurite, Azure Functions Core Tools, and other dependencies.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation demonstrates a mild Windows bias by frequently presenting Windows (cmd) examples alongside Bash, and sometimes listing Windows-specific instructions or terminology first. While Bash examples are provided for most CLI commands, there is a consistent pattern of giving equal or slightly prioritized attention to Windows command prompt (cmd) usage, which may not be necessary for a Java developer audience that is often cross-platform. There are no explicit Linux-only instructions or tools, and some sections (such as environment variable setup) do not clarify differences between Windows and Linux environments. There is also a lack of explicit Linux troubleshooting or environment-specific guidance, and no mention of Linux-native editors or shells beyond Bash.

Recommendations:

Wherever command-line examples are given, consider listing Bash (Linux/macOS) examples first, as these are more universally applicable for Java developers.
Reduce the prominence of Windows cmd examples, or move them to expandable sections to avoid cluttering the main flow for cross-platform users.
Add explicit notes or troubleshooting tips for Linux environments, such as file permissions, case sensitivity, or common issues with environment variables.
Include references to Linux-native editors (e.g., Vim, Emacs, Nano) in addition to IDEs, or at least acknowledge their use in terminal-based workflows.
Ensure that all instructions for setting environment variables, file paths, and permissions are cross-platform, with clear distinctions where necessary.
Provide parity in troubleshooting and setup guidance for both Windows and Linux, especially in sections dealing with local development, environment variables, and deployment.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation demonstrates a moderate Windows bias, primarily through the prominent mention and detailed discussion of PowerShell modules (Az and AzureRM) before Azure CLI, and by referencing Windows/PowerShell-specific tools and patterns (e.g., Visual Studio, System Center Operations Manager) without equivalent Linux or cross-platform alternatives. While Azure CLI is mentioned, PowerShell is often foregrounded or discussed in greater detail, and some example scripts are written in PowerShell syntax. There is a lack of explicit Linux shell (bash) examples, and Windows-centric tools are referenced without noting Linux alternatives.

Recommendations:

Provide Linux shell (bash) equivalents for all PowerShell command examples, especially for Azure CLI usage.
When referencing PowerShell modules, also mention cross-platform compatibility or provide links to Linux installation guides.
Ensure that tools like Visual Studio and System Center Operations Manager are accompanied by references to cross-platform or Linux-native alternatives where available (e.g., VS Code, open-source monitoring tools).
In lists or instructions, avoid always mentioning Windows/PowerShell first; alternate or present CLI/bash examples first in some sections.
Explicitly state when tools or instructions are cross-platform, and clarify any OS-specific limitations or differences.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page exhibits a mild Windows bias. Specifically, it references Windows-specific documentation for creating Proximity Placement Groups (PPGs) (linking to /azure/virtual-machines/windows/proximity-placement-groups-portal) without mentioning or linking to equivalent Linux documentation or workflows. There are no explicit PowerShell or Windows command examples, but the absence of Linux-specific guidance or parity in referenced materials may disadvantage Linux users. No Linux tools, commands, or portal links are provided, and the only example for PPG creation is Windows-focused.

Recommendations:

Include links to both Windows and Linux documentation for tasks such as creating Proximity Placement Groups (e.g., /azure/virtual-machines/linux/proximity-placement-groups-portal).
Where referencing Azure portal workflows, clarify that the steps are applicable to both Windows and Linux VMs, or provide separate instructions if there are differences.
Add examples or notes relevant to Linux-based SAP HANA deployments, especially in sections discussing VM pinning, PPGs, and availability sets.
Audit all external links and references to ensure Linux parity and avoid Windows-first impressions.
If any CLI or PowerShell examples are added in the future, ensure equivalent Bash/Azure CLI examples are provided.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation page demonstrates a Windows bias by providing only Windows-based instructions and tools for managing SMB volumes, such as using the Windows Security tab and Microsoft Management Console (MMC) for permissions. There are no Linux or cross-platform examples for accessing or managing SMB shares, and Windows terminology and tools are referenced exclusively or before any mention of Linux equivalents.

Recommendations:

Include instructions and examples for managing SMB share and NTFS permissions from Linux clients, such as using 'smbclient', 'smbcacls', or 'setfacl'.
Provide Linux command-line examples for mounting SMB volumes (e.g., using 'mount -t cifs' or 'smbclient') alongside or before Windows examples.
Mention Linux-compatible tools and workflows for SMB management, not just Windows MMC or File Explorer.
Clarify which features (such as SMB3 encryption or access-based enumeration) are supported and how to configure them from Linux clients.
Add screenshots or terminal outputs from Linux environments where appropriate.
Ensure that all steps referencing Windows tools have Linux equivalents or explicitly state if a feature is only available via Windows.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias in its command-line examples and tooling. PowerShell commands are shown first and in detail for feature registration, with Azure CLI commands only mentioned secondarily and without explicit examples. There are no Linux-specific instructions or screenshots, and the workflow descriptions (e.g., 'right-click') assume a GUI experience typical of Windows environments. No Linux or cross-platform command-line examples are provided for key operations.

Recommendations:

Provide explicit Azure CLI command examples (e.g., 'az feature register', 'az feature show') alongside or before PowerShell examples, as Azure CLI is cross-platform and widely used on Linux.
Include Linux-specific instructions or notes where relevant, especially for command-line operations.
Avoid GUI instructions that assume a Windows environment (such as 'right-click') or supplement them with equivalent CLI steps.
Ensure screenshots and workflow descriptions are platform-neutral or provide alternatives for Linux users.
Where possible, use cross-platform terminology and tools as the primary examples, with Windows-specific tools as secondary.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a mild Windows bias in the way it presents tooling and examples. In the 'Ways to create snapshots' section, PowerShell is listed as a primary tool alongside Azure Portal, REST API, and Azure CLI, but there is no mention of Linux-specific tools or shell scripting. The only scripting example linked is for SQL Server (a Windows-centric workload). There are no explicit Linux/Bash examples or references to Linux-native patterns, and PowerShell is mentioned before any Linux alternatives. This could make Linux users feel less directly supported.

Recommendations:

Include explicit Bash/Unix shell examples for snapshot management using Azure CLI, especially for common Linux administration scenarios.
When listing tools, present Azure CLI and REST API before PowerShell, or group them neutrally, to avoid the impression of Windows-first bias.
Add references or links to Linux scripting guides or examples for automating snapshot tasks.
If possible, provide sample scripts for both PowerShell and Bash in the documentation or in linked resources.
Mention that Azure CLI is cross-platform and can be used on Linux, macOS, and Windows, to reinforce platform neutrality.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias by prioritizing Windows/SMB and Active Directory scenarios, referencing Windows-specific tools and security features (e.g., Group Policy, UNC hardening, Windows Server registry settings) without providing equivalent Linux or open-source alternatives. Examples and configuration guidance are almost exclusively Windows-centric, with little to no mention of Linux tools, commands, or client configuration steps. Linux/NFS encryption is discussed, but without practical configuration examples or parity in depth compared to Windows/SMB sections.

Recommendations:

Provide Linux client configuration examples for NFS Kerberos encryption, including commands for setting up krb5, krb5i, and krb5p on common distributions.
Include Linux-based LDAP client configuration steps for enabling LDAP signing and StartTLS, such as using OpenLDAP tools and relevant configuration files.
When discussing SMB encryption, add guidance for SMB clients on Linux (e.g., using smbclient, mount.cifs with encryption options) and note any differences in support or configuration.
Balance references to Windows-specific tools (e.g., Group Policy, registry settings) with Linux equivalents or note when features are not available/can be configured differently on Linux.
Add troubleshooting and verification steps for both Windows and Linux clients to ensure encryption is active (e.g., using tcpdump, Wireshark, or relevant logs).
Explicitly state support and configuration differences for cross-platform environments, and provide links to Linux documentation where appropriate.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page focuses on assessing .NET web apps for migration to Azure App Service but implicitly assumes a Windows-centric environment. There are no explicit examples or mentions of Linux-based .NET web apps, nor are Linux-specific tools or considerations discussed. The linked resources and terminology (e.g., ASP.NET, which historically is Windows-focused) further reinforce this bias.

Recommendations:

Include explicit mentions and examples of assessing .NET web apps running on Linux (e.g., ASP.NET Core on Linux).
Reference Linux-based tools or command-line instructions (such as Bash scripts or Linux-native assessment tools) alongside any Windows or PowerShell examples.
Clarify in the documentation whether the assessment process and recommendations apply equally to both Windows and Linux-hosted .NET web apps.
Add links to resources or tutorials specifically addressing Linux-based .NET app assessment and migration.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation assumes a development environment based on GitHub Codespaces and .NET, but does not provide explicit instructions or examples for Linux or non-Windows local development environments. All terminal commands and deployment steps are generic, but there is an implicit bias toward Windows-centric workflows (e.g., Visual Studio Code, Codespaces, Azure CLI) without acknowledging or providing parity for Linux-specific tools, shell environments, or deployment patterns. There are no PowerShell-specific commands, but the absence of Linux-specific terminal or deployment instructions constitutes a subtle Windows-first and missing-Linux-example bias.

Recommendations:

Explicitly mention that the tutorial works on both Windows and Linux, and provide any necessary shell command differences (e.g., path separators, environment variable syntax).
Include examples or notes for running the sample app and deploying from a local Linux environment (e.g., using Bash, zsh, or Linux-native .NET SDK).
Add troubleshooting tips or prerequisites for Linux users, such as installing the .NET SDK, Azure CLI, and ensuring compatibility with Linux distributions.
If using Codespaces, clarify that it provides a Linux-based environment, and note that all commands are cross-platform unless otherwise stated.
Where relevant, provide alternative instructions for Linux-native editors (e.g., Vim, Emacs, GNOME Terminal) or mention that Visual Studio Code is available on Linux.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation demonstrates configuration management using Azure App Configuration in the context of an ASP.NET Core application. It references modifying 'launchSettings.json' and running the app with 'dotnet build' and 'dotnet run', but does not provide any Linux- or cross-platform-specific guidance or examples. The workflow and tooling described (e.g., launchSettings.json) are more familiar to Windows/Visual Studio users, and there is no mention of Linux environment variable configuration or command-line alternatives.

Recommendations:

Add explicit instructions for setting environment variables on Linux/macOS (e.g., using 'export ASPNETCORE_ENVIRONMENT=Production' in the shell) and running the app from the terminal.
Mention that 'launchSettings.json' is primarily used by Visual Studio and may not be relevant for all development environments, especially on Linux.
Provide cross-platform guidance for testing in different environments, such as command-line examples for both Windows (set ASPNETCORE_ENVIRONMENT=Production) and Linux/macOS (export ASPNETCORE_ENVIRONMENT=Production).
Clarify that the dotnet CLI commands are cross-platform, but environment variable setup may differ between operating systems.
Include a note or table summarizing how to set environment variables for different platforms.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation demonstrates a mild Windows bias by referencing Windows-specific tools and workflows before or more prominently than Linux equivalents. For example, it suggests using Windows Subsystem for Linux (WSL) as the primary way to use redis-cli on Windows, and references Windows Terminal. Additionally, Azure PowerShell is mentioned alongside Azure CLI for retrieving cache keys, which may not be as relevant for Linux users.

Recommendations:

Provide native redis-cli installation instructions for Windows (e.g., via pre-built binaries or Chocolatey), not only via WSL.
When listing methods to retrieve cache keys, list Azure CLI first (as it is cross-platform), and clarify that Azure PowerShell is optional or for users already using PowerShell.
Avoid referencing Windows Terminal as the default terminal for WSL; mention that any terminal emulator can be used.
Ensure that all examples and instructions are equally accessible and clear for Linux, macOS, and Windows users, with platform-specific notes where necessary.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation page presents both Linux and Windows solutions, but there is a subtle Windows bias in the ordering and emphasis of content. Windows/SQL Server solutions are given a dedicated section immediately after Linux, and Windows-specific tools and patterns (such as DFS Namespaces, FSLogix, SMB, and Always-On Failover Cluster) are mentioned prominently. In SAP solutions, Windows references and tools like DFS-N are listed before or alongside Linux equivalents, sometimes with more detail or unique features. Some sections (e.g., Virtual Desktop Infrastructure) are almost exclusively Windows-focused, with little mention of Linux alternatives.

Recommendations:

Ensure Linux and Windows solutions are presented with equal prominence and detail, possibly by interleaving examples or providing parallel Linux alternatives where Windows tools (e.g., DFS, FSLogix, SMB) are discussed.
Where Windows-specific tools or patterns are mentioned (such as DFS-N or FSLogix), include Linux equivalents (such as NFS, autofs, or sssd) and provide links to relevant documentation.
In sections like Virtual Desktop Infrastructure, add references to Linux-based VDI solutions or clarify if the service is Windows-only.
Review the ordering of solution sections to avoid consistently listing Windows solutions before Linux, or alternate the order in different sections.
For SAP and other cross-platform workloads, ensure that Linux and Windows high-availability and disaster recovery patterns are described with equal depth and clarity.

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation demonstrates a 'windows_first' bias by describing the file path configuration for Windows before Linux, and by using a Windows-style path (C:\home\site\wwwroot) in the main instructions and examples. Linux instructions are only mentioned as a note, and Linux-style paths are not used in the main steps or examples.

Recommendations:

Present Linux and Windows instructions/examples side-by-side or in parallel, rather than mentioning Linux only in a note.
Use platform-agnostic language and examples where possible (e.g., refer to 'the root of your project' and show both Windows and Linux paths).
In step-by-step instructions, include both Windows and Linux file path examples (e.g., 'C:\home\site\wwwroot\auth.json' for Windows and '/home/site/wwwroot/auth.json' for Linux).
Explicitly state any platform differences in the main instruction flow, not just in notes.
Consider adding a table or section summarizing platform-specific behaviors for clarity.

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation page lists .NET and ASP.NET Core providers (which are primarily Windows-centric technologies) first in the provider libraries table, with their samples and release notes. There is no explicit mention of Windows-only tools or PowerShell, nor are there missing Linux examples, but the ordering and emphasis on .NET/Windows frameworks before cross-platform or Linux-native stacks (Java, Python, Go, JavaScript) suggests a subtle 'windows_first' bias.

Recommendations:

Reorder the provider libraries table to group or order entries by language popularity or cross-platform relevance, rather than placing .NET/Windows-centric frameworks first.
Explicitly mention the cross-platform nature of .NET Core and clarify which providers are suitable for Linux environments.
Provide a brief section or callout highlighting Linux usage, including any platform-specific considerations or links to Linux-focused samples.
Ensure that all sample links and documentation are equally accessible and relevant for both Windows and Linux users.
Consider adding a column or note indicating OS compatibility for each provider to make Linux support more visible.

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation mentions PowerShell before Azure CLI when listing tools for creating resource groups, suggesting a subtle 'windows_first' bias. However, both Windows (PowerShell) and cross-platform (Azure CLI, ARM template, Portal) options are referenced, and no examples or commands are provided that are exclusive to Windows or PowerShell. There are no missing Linux examples, nor are Windows tools or patterns mentioned exclusively.

Recommendations:

When listing tools or methods, alternate the order or explicitly state that both PowerShell and Azure CLI are supported equally.
Provide example commands for both PowerShell and Azure CLI (and/or Bash) where relevant, ensuring parity.
Consider adding a note that Azure CLI is cross-platform and can be used on Windows, Linux, and macOS.
Avoid consistently listing PowerShell before Azure CLI to prevent the perception of Windows-first bias.

Create pull request

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