Scan Details - Linux-first Docs for Azure

186

Pages Scanned

37

Pages Flagged

186

Changed Pages

19.9%

% Pages Flagged

Live Progress

🔴 Connecting...

0%

Phase: discovery

Processing: Initializing...

Activity Feed

00:01:13 Scan started

Scan Information

Started At: 2025-08-30 00:01:13

Finished At: In Progress

Status: in_progress

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

Current Phase: discovery

Problematic Pages

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation page demonstrates a Windows bias by primarily referencing Azure PowerShell scripts and cmdlets for migration and preview registration tasks, with no equivalent Bash or Linux-native CLI examples. The 'Next steps' section also prioritizes PowerShell tutorials, and the use of 'Set-AzContext' and similar commands is specific to PowerShell, which is more familiar to Windows users. There is no mention of Bash, Linux, or cross-platform CLI usage, and Linux users are not directly addressed.

Recommendations:

Provide Azure CLI (bash/shell) command examples alongside or before PowerShell commands for all tasks, especially for migration and preview registration.
Include explicit references to Linux/macOS compatibility and usage where relevant.
Balance tutorial links in the 'Next steps' section by including guides that use Azure CLI in Bash or cross-platform environments.
Avoid assuming PowerShell as the default scripting environment; clarify when commands are PowerShell-specific.
Where possible, use generic Azure CLI commands (az ...) instead of PowerShell-specific cmdlets (Set-AzContext, Register-AzProviderFeature, etc.), or provide both.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows bias by providing only a PowerShell example for resource cleanup (Remove-AzResourceGroup), referencing IIS (a Windows web server) as the default backend for validation, and omitting any Linux/CLI equivalents or examples for these steps. There are no instructions or examples for users on Linux or macOS platforms, particularly for resource cleanup or backend validation.

Recommendations:

Provide equivalent Azure CLI commands for resource group deletion (e.g., az group delete --name <group-name>), and present them alongside or before PowerShell examples.
Include backend validation steps using a Linux-friendly web server (such as Nginx or Apache) or clarify how to adapt the validation for non-Windows environments.
Ensure that all code snippets and instructions are cross-platform, or clearly indicate which steps are specific to Windows and provide alternatives for Linux/macOS users.
Consider using neutral language and examples (e.g., 'web server' instead of 'IIS') unless the scenario specifically requires Windows.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation is heavily focused on Windows-based migration scenarios, tools, and patterns. All migration tools and examples target Windows environments, specifically IIS servers, and PowerShell scripts. There is no mention of Linux-based .NET hosting environments, migration from Linux servers, or equivalent Linux tools or scripts. The documentation assumes the source environment is always Windows/IIS, and all downloadable tools are Windows executables or PowerShell scripts.

Recommendations:

Add guidance and examples for migrating .NET apps hosted on Linux servers (e.g., Apache, Nginx, Kestrel) to Azure App Service.
Include Linux-compatible migration tools or scripts, or clearly state if such tools are not available.
Provide parity in documentation by listing Linux migration scenarios and tools alongside Windows ones, not just as an afterthought.
Offer Bash or cross-platform CLI examples in addition to PowerShell.
Clarify App Service support for Linux-based .NET workloads and provide links to relevant documentation.
If Windows-only tools are a limitation, explicitly call this out and suggest manual migration steps for Linux users.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows bias by referencing Windows-specific tools and patterns (such as web.config and iisnode) without providing equivalent Linux guidance or examples. Linux-specific configuration and troubleshooting steps are largely absent, and Windows approaches are mentioned first or exclusively in several sections.

Recommendations:

For auto-healing configuration, provide Linux-native guidance (such as using application settings, environment variables, or Linux-specific configuration files) alongside or instead of web.config, which is Windows/IIS-specific.
When discussing Node.js hosting, include Linux process managers (such as PM2, which is mentioned, but also clarify differences from iisnode) and provide examples for both Windows and Linux environments.
Where iisnode is referenced, add parallel information for Linux-based Node.js hosting (e.g., using PM2, systemd, or other process managers) and clarify when each is applicable.
Ensure that all troubleshooting and best practice steps are described for both Windows and Linux App Service plans, or clearly indicate when a feature is platform-specific.
Review all examples and instructions to ensure Linux parity, adding Linux shell commands or configuration examples where only Windows/Powershell/web.config are currently shown.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation demonstrates a mild Windows bias by presenting Windows-related information and tools before their Linux equivalents. For example, in the 'Premium V3 availability' section, the Windows SKU availability command is shown before the Linux command. The automation section provides both Azure CLI and Azure PowerShell examples, but PowerShell (a Windows-centric tool) is given equal prominence, and there are no explicit Linux shell (bash) script examples. Additionally, the use of Azure PowerShell is highlighted, which is more familiar to Windows users.

Recommendations:

Present Linux and Windows options in parallel or randomize their order to avoid always listing Windows first.
Include explicit bash shell scripting examples alongside Azure PowerShell to improve parity for Linux users.
Clarify that Azure CLI commands work cross-platform and can be run in bash, zsh, or other Linux shells.
Where possible, provide screenshots or instructions for both Windows and Linux environments, especially for command-line tasks.
Consider adding a note that Azure PowerShell is available cross-platform, but that bash scripting is also supported and common on Linux.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias by presenting Windows-related information and tools first, providing Azure PowerShell examples (which are Windows-centric) without equivalent Bash or Linux shell scripting examples, and referencing Windows-specific deployment scenarios before Linux. While Azure CLI commands are cross-platform, the PowerShell section lacks Linux parity. There is also a lack of explicit Linux container deployment automation examples.

Recommendations:

Provide Bash or Linux shell script equivalents for all Azure PowerShell examples, especially for automating tasks.
Ensure Linux-specific deployment scenarios (such as custom containers) are given equal prominence and example coverage as Windows scenarios.
When listing availability or commands, alternate the order or present Windows and Linux options side by side to avoid 'Windows first' ordering.
Include explicit examples for deploying and scaling Linux container apps, not just source code apps.
Clarify in each automation section which commands are cross-platform and which are Windows-specific, to guide users appropriately.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates several forms of Windows bias. Windows instructions and tools (such as the GUI and PowerShell commands) are often presented first or exclusively, with Linux alternatives either missing, less detailed, or relegated to secondary status. The troubleshooting section, for example, provides PowerShell commands for connectivity checks but omits equivalent Linux commands. The Hybrid Connection Manager GUI is only available on Windows, and this is noted, but the Linux CLI experience is less visually supported and lacks parity in some explanations. Windows-specific tools and patterns (like right-clicking in the portal or using MSI installers) are mentioned more prominently or exclusively.

Recommendations:

Provide Linux command-line equivalents for all troubleshooting steps, such as using 'nc' or 'telnet' instead of PowerShell's 'Test-NetConnection'.
When listing instructions or examples, alternate the order or present both Windows and Linux options side by side, rather than always leading with Windows.
Where GUI tools are Windows-only, enhance Linux documentation with screenshots and detailed CLI workflows to achieve parity.
Avoid Windows-centric language such as 'right-click' in portal instructions, or clarify how these actions are performed on other platforms.
Expand Linux installation and upgrade instructions to match the detail and clarity of the Windows MSI process.
Ensure that all examples, especially for connectivity testing and troubleshooting, are provided for both Windows and Linux environments.

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 PowerShell scripts for advanced resource identification (e.g., identifying Traffic Manager endpoints and retrieving both site properties and config values). There are no equivalent Bash, Azure CLI, or cross-platform script examples provided for Linux or Mac users. The documentation assumes access to and familiarity with PowerShell, which is traditionally a Windows-centric tool, although it is now available cross-platform. However, no Linux-native or Bash alternatives are mentioned, and PowerShell is referenced as the default scripting environment for automation tasks.

Recommendations:

Provide equivalent Bash or Azure CLI script examples for all PowerShell scripts referenced, ensuring Linux and Mac users can perform the same tasks without needing PowerShell.
When referencing scripts, clarify if they are cross-platform or provide explicit instructions for running them on Linux/Mac (e.g., using PowerShell Core).
List Azure CLI and REST API options before or alongside PowerShell to avoid the impression that Windows tools are preferred or required.
Where possible, use Azure CLI for automation examples, as it is natively cross-platform and familiar to both Windows and Linux users.
Explicitly mention that PowerShell scripts can be run on Linux/Mac with PowerShell Core, or provide links to documentation on installing PowerShell on those platforms.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page focuses exclusively on discovery of ASP.NET web apps running on IIS web servers within VMware environments, which are Windows-centric technologies. There are no examples or mentions of discovering .NET apps hosted on Linux (e.g., Kestrel, Apache, Nginx), nor are Linux tools or patterns referenced. The documentation assumes a Windows/IIS environment and omits Linux scenarios entirely.

Recommendations:

Include information about discovering .NET web apps hosted on Linux servers, such as those running Kestrel behind Nginx or Apache.
Provide parallel examples or guidance for Linux-based environments, including any limitations or differences in Azure Migrate support.
Mention Linux-compatible discovery tools or scripts if available, or clarify if discovery is currently Windows-only.
Rephrase content to avoid assuming IIS/Windows as the default or only scenario for .NET app hosting.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ powershell_heavy

Summary:

The documentation is heavily focused on Windows environments, specifically Azure App Service on Windows with iisnode. All configuration and troubleshooting steps are tailored to Windows, referencing Windows-specific tools (e.g., iisnode, web.config, node.exe, Win32 error codes, Kudu CMD/PowerShell), and file paths use Windows conventions. There are no Linux or cross-platform examples, and Linux equivalents (such as Azure App Service for Linux or Linux-based Node.js hosting patterns) are not mentioned.

Recommendations:

Add a parallel section or separate documentation for Node.js on Azure App Service for Linux, covering equivalent best practices and troubleshooting steps.
Include Linux-based configuration and deployment examples, such as using PM2, NGINX, or systemd, and reference Linux file paths and conventions.
When discussing tools like Kudu, provide guidance for both Windows (CMD/PowerShell) and Linux (Bash/SSH) environments.
Avoid assuming the presence of Windows-specific files (e.g., web.config, node.exe) and instead mention cross-platform alternatives where possible.
Reference both Windows and Linux error codes and diagnostic methods, and provide links to relevant Linux documentation.
Clearly indicate at the top of the article that the content is specific to Windows, and provide a link to Linux-focused documentation for parity.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation demonstrates a mild Windows bias by referencing Azure Storage Explorer (which is primarily a GUI tool with a strong Windows user base) and linking to instructions with a '?tabs=windows' parameter, suggesting a Windows-first approach. There are no explicit Linux or cross-platform command-line alternatives provided for generating SAS tokens or uploading files, and no mention of Linux-native tools or workflows. All command-line examples use Azure CLI, which is cross-platform, but the initial file upload and SAS generation steps are Windows-centric.

Recommendations:

Include explicit Linux and macOS instructions or clarify that Azure Storage Explorer is available cross-platform, if applicable.
Provide command-line alternatives (e.g., using 'az storage blob upload' and 'az storage blob generate-sas') for uploading files and generating SAS tokens, ensuring parity for users on Linux and macOS.
Avoid using '?tabs=windows' in links or ensure that Linux/macOS tabs are equally prominent and referenced.
Mention and link to documentation for Linux-native tools or CLI workflows wherever a GUI tool is suggested.
Add a note or section highlighting cross-platform compatibility and any OS-specific considerations.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows bias by exclusively referencing Windows-based tools and workflows (such as Visual Studio, Kudu, CMD/PowerShell, and Windows file paths) when discussing configuration and diagnostics for ASP.NET apps on Azure App Service. There are no Linux-specific instructions or examples, and the documentation assumes the use of Windows environments throughout.

Recommendations:

Add equivalent Linux-based instructions and examples for each configuration task, such as using Bash or SSH in Kudu for Linux-based App Service plans.
Include file paths and commands relevant to Linux containers or App Service on Linux (e.g., /home/site/wwwroot).
Mention and provide examples for deploying and configuring ASP.NET apps on App Service for Linux, not just Windows.
Clarify when instructions are Windows-specific and provide parallel guidance for Linux scenarios.
Reference cross-platform tools (such as VS Code, Azure CLI, or GitHub Actions) alongside or instead of Windows-only tools like Visual Studio.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation provides both Linux and Windows instructions for configuring data sources in Tomcat and JBoss on Azure App Service. However, in the Tomcat server-level configuration section, the Windows instructions are more detailed and rely heavily on Windows-specific tools (PowerShell, .cmd scripts, Windows environment variables). The Windows workflow is described after the Linux one, but the Windows steps are more elaborate, with more code and explanation. There is also a strong reliance on PowerShell and Windows file paths, while the Linux instructions use standard shell scripting and tools. Both platforms are covered, but the Windows approach is more thoroughly documented and uses Windows-specific tools.

Recommendations:

Ensure Linux and Windows sections have parity in detail and clarity. For example, provide more detailed Linux startup script examples, troubleshooting tips, and explanations similar to the Windows section.
Where possible, use cross-platform tools or provide equivalent Linux-native commands/scripts for every Windows PowerShell example.
Avoid assuming PowerShell or Windows CMD as the default scripting environment; always provide a Bash/sh alternative.
Highlight Linux-native file paths, environment variables, and deployment patterns as prominently as Windows ones.
Consider adding a summary table comparing the steps for Linux and Windows to help users quickly find the relevant instructions for their platform.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation provides both Linux and Windows examples for most tasks, but there are several areas where Windows is prioritized or receives more detailed coverage. Windows-specific tools (Kudu, FTPS, web.config) are mentioned, sometimes without Linux equivalents or with less detail. In some sections, Windows instructions appear before Linux, and certain advanced troubleshooting or deployment patterns (e.g., Kudu Process Explorer, web.config notes) are Windows-centric. Some features, such as Tomcat patch version pinning, are described as more flexible on Windows than Linux. There are also references to legacy Windows deployment conventions and tools without Linux alternatives.

Recommendations:

Ensure that Linux examples are always present and as detailed as Windows ones, especially for advanced troubleshooting and deployment scenarios.
Where Windows tools (e.g., Kudu, FTPS, web.config) are mentioned, provide Linux equivalents or clarify Linux alternatives (e.g., SSH, SCP, Linux config files).
Avoid presenting Windows instructions before Linux unless there is a technical reason; consider using neutral or Linux-first ordering.
Expand documentation for Linux-specific workflows, such as container debugging, file access, and deployment, to match the depth of Windows coverage.
Clarify any feature parity differences (e.g., Tomcat patch version pinning) and provide guidance for Linux users where limitations exist.
Review all notes and tips to ensure Linux users are not left with unanswered questions or missing context compared to Windows users.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows-first bias by describing Windows container SSH access before Linux, and by providing more detail and ease-of-use for Windows containers (no modifications needed) while Linux containers require extra configuration. There are no PowerShell-heavy examples, but the Windows section lacks parity with the Linux section, which provides detailed CLI examples. The Linux section is more comprehensive, but the initial focus and simplicity for Windows containers, as well as the lack of equivalent command-line tooling for Windows, indicate a bias.

Recommendations:

Provide equivalent command-line (e.g., PowerShell or Windows CLI) instructions for SSH access to Windows containers, or explicitly state their absence and offer alternatives.
Present Linux and Windows instructions in parallel, with equal detail and order, to avoid a 'Windows-first' impression.
Clarify any feature gaps (e.g., lack of Azure CLI support for Windows containers) and suggest workarounds or roadmap information.
Ensure that both Linux and Windows sections include practical examples and troubleshooting tips.
If Windows containers do not support CLI-based SSH, explain why, and provide guidance for users who may expect this feature.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation exhibits a Windows-first bias by referencing Windows file paths (e.g., D:\home\site\wwwroot) before Linux equivalents, and by providing operational details (such as directory structure and deployment artifacts) primarily in Windows terms. There are no explicit Linux command-line or file path examples, and Linux-specific nuances are not discussed. The documentation also references Windows-style directory separators (\) and omits Linux shell or deployment tool examples, despite mentioning that App Service supports Linux.

Recommendations:

Present both Windows and Linux file paths and directory structures side by side throughout the documentation (e.g., D:\home\site\wwwroot and /home/site/wwwroot).
Include Linux shell (bash) command examples where relevant, especially for file operations or manual deployment steps.
Clarify when instructions or behaviors differ between Windows and Linux App Service plans.
Avoid using only Windows-style directory separators (\); provide Linux-style (/) as well.
Add troubleshooting notes or caveats specific to Linux deployments, if any.
Ensure that any referenced tools (e.g., Azure Storage Explorer) are cross-platform or suggest Linux alternatives if needed.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page exhibits a moderate Windows bias, particularly in the .NET/ASP.NET sections. Windows tools (Visual Studio, PowerShell) are listed before or alongside cross-platform or Linux alternatives, and some examples or quickstarts default to Windows or PowerShell. In other stacks (Java, Node.js, PHP), Linux and CLI options are more prominent, but the 'Next step' callout at the end defaults to an ASP.NET (Windows-centric) quickstart. Some Python quickstarts also default to Windows tabs, and Linux parity is inconsistent across stacks.

Recommendations:

Ensure that Linux and cross-platform CLI examples are always presented alongside or before Windows/PowerShell examples, especially in .NET/ASP.NET sections.
For each stack, provide explicit Linux and macOS instructions where relevant, not just Windows or Visual Studio/PowerShell.
In the .NET/ASP.NET tables, add or highlight Linux/CLI options (e.g., .NET CLI on Linux, VS Code on Linux) and avoid listing Windows tools first.
Review tab defaults in quickstart links to avoid defaulting to Windows/PowerShell unless the stack is Windows-only.
Balance the 'Next step' callout to include a Linux or cross-platform example, or provide a choice of next steps for different platforms.
Audit all quickstart and tutorial links to ensure Linux parity and that Linux users are not required to adapt Windows-specific instructions.

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 NuGet Package Manager in Visual Studio) and omitting explicit Linux or cross-platform command-line examples for key steps such as file creation and package installation. There are no Linux-specific instructions or terminal/CLI-based workflows for non-Windows users, and the documentation assumes the use of the Azure Portal GUI for environment variable management, which may not be the primary workflow for Linux users.

Recommendations:

Provide equivalent Linux and cross-platform instructions for all steps, especially for file creation, navigation, and package installation (e.g., using dotnet CLI and text editors like VS Code or nano).
Include CLI-based examples for managing environment variables and deploying to App Service, such as using Azure CLI or scripting.
Avoid assuming Visual Studio or Windows GUI usage as the default; mention cross-platform editors and tools early and equally.
Add explicit notes or sections for Linux/macOS users, ensuring parity in setup and deployment workflows.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ windows_first

Summary:

The documentation page demonstrates a strong Windows bias by exclusively providing PowerShell examples for per-app scaling, with no equivalent examples for Linux-native tools or cross-platform CLI (such as Azure CLI or Bash). The only scripting examples use PowerShell cmdlets, which are traditionally associated with Windows environments. There is no mention of Linux command-line tools or workflows, and the PowerShell approach is presented first and exclusively, reinforcing a Windows-centric perspective.

Recommendations:

Add equivalent Azure CLI (az) examples for all PowerShell commands, as Azure CLI is cross-platform and widely used on Linux and macOS.
Include Bash script examples for configuring per-app scaling, or at least show how to invoke Azure CLI commands from Bash.
Explicitly mention that PowerShell examples can be run on Linux/macOS using PowerShell Core, or clarify platform compatibility.
Reorder or parallelize examples so that Linux-friendly (CLI/Bash) and Windows (PowerShell) approaches are presented side-by-side or with equal prominence.
Reference Linux tools and workflows where appropriate, and avoid assuming a Windows-only environment.

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 there are no explicit Linux shell or bash-specific examples beyond the use of Azure CLI. The only direct shell command shown outside of Azure CLI/PowerShell is 'nslookup', which is cross-platform. However, outbound IPv6 support is called out as being available only for Windows apps, with no Linux parity. There are no Linux-specific tools or workflows mentioned, and PowerShell is referenced without noting its cross-platform availability.

Recommendations:

Explicitly state that Azure CLI commands work on Linux, macOS, and Windows, and that PowerShell Core is cross-platform.
Add bash or Linux-native command examples where appropriate, such as using 'curl' or 'dig' for DNS/IP lookups.
When listing command examples, alternate the order (e.g., sometimes show CLI first, sometimes PowerShell) or clarify that both are supported on all platforms.
Provide a note or roadmap for when outbound IPv6 support will be available for Linux apps, or clarify the limitation more prominently.
Where PowerShell is used, specify if it is Windows PowerShell or cross-platform PowerShell Core, and provide installation links for non-Windows users.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page exhibits a Windows-first bias. File paths and folder structures are consistently described using Windows conventions (e.g., D:\home), with no mention of Linux equivalents. Tools and features such as Kudu (SCM) are referenced without clarifying their availability or differences on Linux App Service. There are no Linux-specific examples or instructions, and the only mention of Linux is to state that the local cache feature is not supported for Linux containers, with no further guidance for Linux-based App Service users.

Recommendations:

Include Linux-specific file paths and folder structure examples (e.g., /home/site/wwwroot) alongside Windows paths.
Clarify which features and tools (such as Kudu/SCM) are available or behave differently on Linux App Service.
Provide equivalent instructions and examples for configuring local cache or its alternatives on Linux-based App Service plans.
Explicitly state the differences in feature support and behavior between Windows and Linux App Service, and link to Linux-relevant documentation where appropriate.
Where features are unsupported on Linux, offer guidance or alternatives (such as App Cache) with clear instructions for Linux users.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a mild Windows bias. It provides detailed calculations and limits specifically for Windows Containers, while Linux equivalents are not discussed. Windows-specific features (e.g., Windows Server Active Directory domain join, NetBIOS) are mentioned in the 'not supported' list, but Linux-specific scenarios are not addressed. The only explicit Linux mention is in the context of continuous deployment, which is brief and lacks parity with the detailed Windows section. There are no Linux-specific examples, tools, or troubleshooting steps provided.

Recommendations:

Add a comparable section for Linux Containers, including subnet/IP calculations and any unique limitations or requirements.
Provide Linux-specific examples or scenarios where relevant, such as networking behaviors or integration caveats.
Ensure that troubleshooting and operational guidance covers both Windows and Linux App Service plans equally.
Mention Linux-specific networking features or limitations, if any, to provide balanced coverage.
Where Windows-only features are listed as unsupported, clarify if there are Linux equivalents and their support status.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation exhibits a Windows-first and Windows-heavy bias in several areas. Windows-specific paths, tools, and terminology are often mentioned before or instead of Linux equivalents. Many environment variables and examples reference Windows conventions (e.g., D:\home, %HOME%, .bat files, w3wp.exe), and Windows-specific tools like MSDeploy and Web Deploy are described in detail, while Linux alternatives are less prominent or missing. Some settings are described as 'Windows only' or default to Windows behaviors, and Linux-specific details are sometimes only provided as afterthoughts or not at all.

Recommendations:

For every Windows-specific path or example (e.g., D:\home, %HOME%), provide the Linux equivalent (/home, $HOME) side-by-side.
When describing tools or deployment methods (e.g., MSDeploy, Web Deploy), also mention and document Linux-native alternatives (such as Oryx, Kudu for Linux, or SCP/rsync) with equal prominence.
Avoid using Windows environment variable syntax (%VAR%) exclusively; always include Linux syntax ($VAR) in parallel.
For settings that behave differently on Windows and Linux, clearly document both behaviors and provide usage examples for each platform.
Where Windows-specific processes or binaries are referenced (e.g., w3wp.exe, .bat files), add Linux equivalents or clarify when there is no equivalent.
Review all sections for missing Linux examples or explanations, and add them to ensure parity.
Consider reordering content so that Windows and Linux are presented equally, rather than always listing Windows first.

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 not described for Linux. Linux instructions are less detailed, and some features are missing entirely for Linux. Additionally, Windows-specific tools and formats (e.g., W3C log format, Log Parser, Web.config) are referenced without Linux equivalents.

Recommendations:

Provide equivalent step-by-step instructions and feature coverage for Linux App Service apps, or clearly state feature parity gaps.
Include Linux-specific examples and tools for accessing, parsing, and analyzing logs (e.g., using tail, grep, less, jq, or open-source log viewers).
When referencing log formats or tools (e.g., W3C, Log Parser), mention if/how Linux logs can be parsed or viewed, and suggest cross-platform alternatives.
Clarify which features are Windows-only at the start of each section, and offer workarounds or alternatives for Linux where possible.
Add code snippets or configuration examples for popular Linux frameworks (Node.js, Python, Java) alongside .NET/Windows examples.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias by referencing Windows-specific tools (IIS, Procdump, SysInternals), focusing on PowerShell for management, and linking to Windows-centric resources. There is little to no mention of Linux equivalents, and Linux-specific troubleshooting steps or tools are absent, despite Azure App Service supporting Linux environments.

Recommendations:

Include Linux-specific examples and instructions for all troubleshooting steps, such as using Bash or Azure CLI instead of only PowerShell.
Mention Linux equivalents for diagnostic tools (e.g., use of strace, lsof, or gdb for memory dumps instead of Procdump).
Clarify when a feature or tool is Windows-only and provide alternatives for Linux-based App Service plans.
Add links to Linux-focused documentation and update references that currently only point to Windows/IIS resources.
Provide sample code and configuration for both Windows (.NET/IIS) and Linux (Node.js, Python, Apache/Nginx) app stacks where relevant.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ windows_first

Summary:

The documentation demonstrates a bias toward Windows and Microsoft-centric workflows. It assumes the use of .NET (a Microsoft technology), GitHub Codespaces, and Azure App Service, all of which are more commonly associated with Windows environments. There are no explicit Linux or cross-platform terminal examples, and the workflow references tools and patterns (such as NuGet, dotnet CLI, and Azure Developer CLI) that are most familiar to Windows users. No Linux-specific instructions, troubleshooting, or alternative commands are provided.

Recommendations:

Explicitly state that all CLI commands (dotnet, azd) work on Linux, macOS, and Windows, and provide any necessary installation links for Linux users.
Include example terminal commands and screenshots from a Linux shell (e.g., bash) in addition to or instead of Codespaces/Windows-centric environments.
Mention that the sample app and all steps can be run locally on Linux or macOS, not just in Codespaces or Windows.
If any step is different on Linux (such as file paths, environment variables, or permissions), call out those differences.
Reference Linux-native editors (e.g., VS Code on Linux, nano, vim) for code changes, not just Visual Studio or Codespaces.
Add troubleshooting tips for common Linux issues (e.g., permissions, firewall, dotnet installation).

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias in several ways: PowerShell and Windows-specific tools (e.g., AzPowershell, Azure PowerShell, PowerShell@2 tasks) are used or referenced in CI examples and authentication setup, often without equivalent Bash or Linux shell examples. The use of PowerShell is shown in both GitHub Actions and Azure Pipelines, and Windows tools are mentioned before or instead of cross-platform/Linux alternatives. There are no explicit Linux shell (bash/sh) command examples for common developer workflows, and the documentation does not provide parity for Linux-first or cross-platform users.

Recommendations:

For every PowerShell or Windows-specific command or task, provide an equivalent Bash (sh) example, especially for CI/CD steps.
In authentication setup, include Azure CLI (az) commands alongside Azure PowerShell, and clarify which commands are cross-platform.
When referencing tools or scripts (e.g., 'PowerShell@2', 'AzPowershell'), also show how to accomplish the same with Bash or cross-platform alternatives.
Avoid using Windows-specific terminology or tools as the default; instead, present cross-platform or Linux-first options first, or at least side-by-side.
Explicitly mention that all workflows and commands are supported on Linux runners (e.g., Ubuntu) and provide sample shell commands for local Linux development.
Add a section or callout for Linux/macOS users, highlighting any differences or confirming full support.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a moderate Windows bias. Visual Studio Code (VS Code) is emphasized as the primary IDE for running and debugging tests, with screenshots and instructions tailored to this environment, which is most popular on Windows. There is no mention of Linux-specific tools, shells, or editors, nor are there any Linux-specific instructions or screenshots. All CLI and shell commands are generic, but the lack of explicit Linux parity (e.g., mentioning Bash, Linux package managers, or Linux desktop environments) and the exclusive use of VS Code and Azure Portal (both with a strong Windows user base) indicate a subtle preference for Windows workflows. Additionally, there are no explicit Linux or macOS examples, nor any mention of platform-specific considerations for environment variables or authentication.

Recommendations:

Add explicit Linux/macOS instructions and screenshots where relevant, such as showing terminal commands in Bash and referencing common Linux editors (e.g., Vim, Nano) for editing configuration files.
Include notes about setting environment variables in Linux/macOS shells (e.g., export PLAYWRIGHT_SERVICE_URL=...) alongside the .env approach.
Mention and provide examples for running Playwright tests in popular Linux IDEs or editors (e.g., JetBrains IDEs, GNOME Builder), or clarify that the instructions are cross-platform.
Where Visual Studio Code is referenced, note that it is available cross-platform and provide links or instructions for Linux/macOS installation.
Add troubleshooting tips or notes for Linux users, such as permissions, package installation, or differences in CLI usage.
Balance screenshots and instructions to reflect both Windows and Linux environments, or use neutral, cross-platform imagery where possible.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation exhibits a Windows bias by using PowerShell syntax for all command-line examples (e.g., git, npm, npx commands), and by referring to 'terminal or command window' without clarifying cross-platform differences. There are no explicit Linux/macOS shell examples or notes about platform-specific differences, and the use of PowerShell prompt style (```powershell) may confuse Linux/macOS users. Additionally, Visual Studio Code is listed as a prerequisite without mention of alternative editors, which may reinforce a Windows-centric workflow.

Recommendations:

Provide all shell command examples using generic shell syntax (e.g., ```sh or ```bash) instead of PowerShell, or show both Windows (PowerShell/CMD) and Linux/macOS (bash/sh) variants side by side.
Explicitly mention that the commands work on Linux/macOS and Windows, and note any platform-specific differences (such as environment variable syntax, path separators, etc.).
In the prerequisites, clarify that Visual Studio Code is cross-platform, and optionally mention that any code editor can be used.
Where 'terminal or command window' is referenced, clarify that this can be PowerShell, Command Prompt, Terminal (macOS), or a Linux shell.
Add a section or callouts for Linux/macOS users, especially for steps involving environment variables, authentication, or file paths.
Avoid using PowerShell-specific code blocks unless there is a Windows-only step; otherwise, prefer neutral shell syntax.

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 and Windows services) are described in detail, with extensive tables and explanations, while Linux equivalents (like daemons) receive less coverage. Example queries and alerting scenarios often use Windows file paths and registry keys before or instead of Linux examples. The documentation also references Windows tools and concepts (e.g., PowerShell, Windows registry, Windows services) more frequently and in greater detail than their Linux counterparts. Some sections (like registry tracking) are Windows-only, and Linux-specific features or limitations are less thoroughly documented.

Recommendations:

Ensure that for every Windows-specific example (e.g., registry keys, file paths, services), a Linux equivalent (e.g., configuration files, systemd units, package managers) is provided and described with equal detail.
Balance example queries and alerting scenarios by including Linux-centric use cases (e.g., tracking changes to /etc/passwd, /etc/ssh/sshd_config, or monitoring systemd service states).
Expand the documentation of Linux-specific features, limitations, and best practices, matching the depth provided for Windows.
Where Windows tools or patterns are mentioned (e.g., PowerShell, registry), include Linux command-line or configuration management equivalents (e.g., Bash, systemctl, /etc directories).
Reorder sections or examples so that Linux and Windows are presented in parallel, rather than Windows-first.
Clarify any feature parity gaps between Windows and Linux, and provide guidance or workarounds for Linux users where features are missing.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation presents environment variable setup instructions for Windows (cmd and PowerShell) before Linux/macOS, and includes both setx (Windows command prompt) and PowerShell examples, which are Windows-specific tools. Linux/macOS instructions are present but always listed after Windows. There are no missing Linux examples, but the ordering and tool emphasis show a Windows-first bias.

Recommendations:

Present Linux/macOS and Windows instructions in parallel (side-by-side tabs) or alternate the order to avoid always listing Windows first.
Avoid giving more prominence to Windows-specific tools (e.g., setx, PowerShell) by grouping all OS instructions equally or using tabs.
Consider providing a brief explanation that environment variable setting methods differ by OS, and link to official OS documentation for details.
Ensure that all examples and instructions are equally detailed for both Windows and Linux/macOS.
Where possible, use cross-platform tools or commands (e.g., recommend using the Azure CLI for authentication and configuration, which works on all platforms).

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation page focuses exclusively on assessing ASP.NET web apps for migration to Azure App Service, but it does not mention Linux-based .NET web apps or provide any Linux-specific guidance or examples. All references and linked resources implicitly assume a Windows environment, with no mention of Linux tools, patterns, or parity.

Recommendations:

Explicitly mention support for both Windows and Linux-based .NET web apps where applicable.
Include examples or notes on assessing .NET Core/ASP.NET Core apps running on Linux environments.
Reference Linux-compatible tools or command-line instructions (e.g., Bash, CLI) alongside any Windows/Powershell examples.
Clarify any differences in assessment steps or recommendations for Linux-hosted web apps.
Ensure linked resources and tutorials also address Linux scenarios or provide parity.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows-first bias by referencing the Windows deployment path (C:\home\site\wwwroot) before mentioning Linux, and only provides a Linux-specific note as an aside. There are no Linux-specific examples or screenshots, and the Linux path is only mentioned in a note, not in the main instructional steps or examples.

Recommendations:

Present both Windows and Linux file paths side-by-side in all relevant steps and examples.
Include explicit Linux examples (e.g., using /home/site/wwwroot/auth.json) in the main instructions, not just in notes.
Clarify platform differences early in the document, possibly with a table summarizing path conventions for both Windows and Linux.
Where possible, provide screenshots or command-line examples for both Windows and Linux environments.
Review for other implicit Windows assumptions (e.g., directory separators, environment variables) and ensure Linux equivalents are always provided.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation page demonstrates configuring environment-specific values in Azure App Configuration using an ASP.NET Core app. All examples and instructions are centered around .NET and the use of launchSettings.json, which is primarily a Visual Studio/Windows-centric pattern. There are no examples or guidance for setting environment variables or running the app in Linux or cross-platform scenarios, such as using shell commands or Docker. The workflow implicitly assumes a Windows development environment.

Recommendations:

Include examples for setting environment variables in Linux/macOS shells (e.g., export ASPNETCORE_ENVIRONMENT=Production) alongside the launchSettings.json method.
Mention how to run the application in Linux environments, possibly using the terminal or Docker, and how to override environment variables at runtime.
Clarify that launchSettings.json is a Visual Studio/.NET Core convention and provide alternative instructions for developers using other editors or platforms.
Add a note or section on cross-platform development, highlighting any differences or additional steps required for Linux/macOS users.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation page demonstrates a mild Windows bias by using the `dos` code block annotation for all redis-benchmark command examples, which implies a Windows Command Prompt environment. There are no explicit Linux shell (bash/sh) examples for redis-benchmark, and the documentation does not mention Linux-specific command-line nuances or provide parity in example formatting. However, the tools discussed (redis-benchmark, memtier-benchmark) are cross-platform, and there is no exclusive mention of Windows-only tools or PowerShell scripts.

Recommendations:

Provide redis-benchmark examples using both Windows (cmd) and Linux (bash/sh) syntax, clearly labeled with appropriate code block annotations (e.g., `cmd`, `bash`).
Mention that redis-benchmark and memtier-benchmark are cross-platform and can be run from both Windows and Linux environments.
Include any Linux-specific installation or usage notes for redis-benchmark (e.g., package manager commands, differences in quoting or environment variables).
Where relevant, add guidance for running commands in PowerShell, Command Prompt, and Bash to ensure parity.
Ensure that code block annotations match the actual shell syntax to avoid confusion for Linux users.

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation demonstrates a subtle Windows bias by listing Windows as the first option in OS-related configuration examples and code snippets, even though Linux is the default. There are no missing Linux examples, and both OS options are documented, but Windows is consistently mentioned or shown before Linux.

Recommendations:

List Linux before Windows in all option lists and code examples, especially since Linux is the default.
Provide code examples that use Linux as the value for the OS setting, or alternate between Linux and Windows in examples.
Explicitly state that Linux is the default and recommended option where relevant.
Ensure parity in any future troubleshooting or tool references (e.g., avoid referencing only Windows tools or PowerShell commands).

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation page lists .NET (and related Microsoft technologies) provider libraries first and in greater detail, with .NET-specific samples and release notes preceding those for Java, Python, JavaScript, and Go. There is a clear ordering that prioritizes Windows-centric technologies, but there are no explicit Windows-only tools, PowerShell examples, or missing Linux examples. The bias is subtle and structural, favoring Windows/.NET ecosystems over others.

Recommendations:

Reorder the provider libraries table to avoid always listing .NET/Microsoft technologies first; consider alphabetical or usage-based ordering.
Add explicit mention that all provider libraries are cross-platform and provide links to platform-agnostic usage guides.
Where possible, include Linux/macOS-specific notes or samples, especially for .NET Core and Java, to reinforce cross-platform support.
Ensure that documentation for each language/platform is equally detailed, with parity in sample links and release notes.
If any CLI or scripting examples are added in the future, provide both Windows (PowerShell/CMD) and Linux (Bash) equivalents.

Create pull request

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