Scan Details - Linux-first Docs for Azure

252

Pages Scanned

50

Pages Flagged

252

Changed Pages

19.8%

% Pages Flagged

Live Progress

🔴 Connecting...

0%

Phase: discovery

Processing: Initializing...

Activity Feed

00:00:56 Scan started

Scan Information

Started At: 2025-09-02 00:00:56

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, and by linking to PowerShell-based tutorials. There are no explicit Linux or Bash examples, and the use of PowerShell is presented as the default or only method for several operations. Azure CLI commands are shown, but the examples use PowerShell-style cmdlets (Set-AzContext, Get-AzProviderFeature), which are not cross-platform. There is no mention of Linux-specific tools, nor are Bash or cross-platform CLI examples provided alongside PowerShell instructions.

Recommendations:

Provide parallel examples using Azure CLI (az) commands in Bash for all PowerShell script references, especially for migration and preview registration.
Clearly indicate when a command is PowerShell-specific and offer equivalent instructions for Linux/macOS users.
Include links to tutorials and documentation that use Bash/Azure CLI as well as PowerShell.
Avoid using PowerShell cmdlets in code blocks labeled as Azure CLI unless they are truly cross-platform.
Add a section or note highlighting cross-platform management options for Azure Application Gateway (e.g., Azure CLI, REST API, ARM templates) and when to use each.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation page exhibits Windows bias by exclusively providing PowerShell commands for resource cleanup, referencing IIS (a Windows web server) for validation, and omitting Linux-specific instructions or examples. The only command-line example is PowerShell, and the validation step assumes IIS is installed on backend VMs, which is a Windows-centric pattern. There are no Linux alternatives or parity in examples, and Windows tools are mentioned before any Linux equivalents (which are absent).

Recommendations:

Provide equivalent Azure CLI commands for resource cleanup (e.g., az group delete) alongside PowerShell examples.
Include instructions for deploying and validating with a Linux-based web server (e.g., Apache or Nginx) in the backend VMs.
Offer Linux shell (bash) examples for interacting with Azure resources and validating deployments.
Explicitly mention cross-platform options and ensure that Linux users are supported throughout the quickstart.
Reorder or parallelize examples so that Windows and Linux approaches are presented together, not Windows-first.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation page demonstrates a strong Windows bias. All migration tools and examples focus exclusively on migrating from Windows environments, specifically from IIS servers. The only scripts and automation mentioned are PowerShell-based, with no mention of Bash, Linux CLI, or Linux-native tools. The App Service Migration Assistant and related resources are only described for Windows workloads. There are no examples or guidance for migrating .NET apps from Linux servers or using Linux-based tools, and Windows terminology and tooling are always mentioned first or exclusively.

Recommendations:

Add explicit guidance and examples for migrating .NET apps hosted on Linux servers (e.g., Apache, Nginx, Kestrel).
Provide Linux-native tooling or scripts (e.g., Bash scripts) for discovery, assessment, and migration, and document their usage.
Include parity in documentation tables and sections for Linux-based migration scenarios, not just Windows/IIS.
Mention cross-platform tools and approaches, such as Azure CLI or containerization workflows that work on both Windows and Linux.
Ensure that migration assistant tools and documentation clarify their platform support and, if possible, expand support for Linux workloads.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a subtle Windows bias. It references Windows-specific configuration files (web.config), mentions iisnode settings for Node.js apps (which are relevant only to Windows hosting), and lacks equivalent Linux configuration examples or references. While there is a brief mention of using PM2 on Linux, the overall guidance and troubleshooting sections focus on Windows tools and patterns, with Linux alternatives either missing or presented secondarily.

Recommendations:

Provide Linux-specific configuration examples alongside Windows ones, such as using app settings or environment variables instead of web.config.
Include guidance for Node.js hosting on Linux (e.g., using PM2, configuring process managers, and relevant settings) in parity with iisnode/Windows guidance.
When referencing tools or configuration files (like web.config or iisnode), clarify their platform scope and offer Linux equivalents (e.g., startup scripts, ecosystem.config.js for PM2).
Ensure troubleshooting and diagnostics sections mention both Windows and Linux approaches where applicable.
Review the order of presentation to avoid always listing Windows/Windows tools first; alternate or present both together.

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. In the 'Premium V3 availability' section, the Windows SKU availability command is listed before the Linux one. The automation section provides both Azure CLI (cross-platform) and Azure PowerShell (Windows-centric) examples, but the PowerShell example is given equal prominence, despite PowerShell being less common on Linux. The UI instructions and screenshots are based on the Azure Portal, which is platform-agnostic, but no mention is made of Linux-specific considerations or tools beyond the CLI command.

Recommendations:

Present Linux and Windows options in parallel or alternate their order to avoid always listing Windows first.
Clarify that Azure PowerShell is available cross-platform, but note its prevalence on Windows and suggest Bash/CLI for Linux users.
Add explicit Linux-focused automation examples, such as Bash scripts or references to ARM/Bicep templates, to balance the PowerShell example.
Where relevant, mention any Linux-specific considerations or differences in the scaling process.
Ensure that all command-line examples are clearly labeled for their intended platform, and consider providing more Linux-native context where possible.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation exhibits a moderate Windows bias. Windows is mentioned first in SKU availability examples, and Azure PowerShell (a Windows-centric tool) is given equal prominence to Azure CLI for automation, without mentioning Linux-native scripting or shell examples. The use of PowerShell as a primary automation example and the ordering of Windows before Linux in several sections reinforce this bias. There are no explicit Linux shell (bash) or scripting examples beyond the Azure CLI, and the documentation does not address Linux-specific concerns or patterns outside of a single CLI flag.

Recommendations:

Alternate the order of Windows and Linux examples, or present Linux examples first where appropriate.
Provide bash or shell scripting examples for automation, not just Azure CLI and PowerShell.
Explicitly mention that Azure CLI commands work cross-platform and can be run natively on Linux/macOS, not just in Cloud Shell.
Include Linux-specific troubleshooting or configuration notes where relevant.
Ensure parity in screenshots and UI walkthroughs for both Windows and Linux app scenarios.

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 examples are often presented first or exclusively, especially in troubleshooting and management sections. PowerShell commands are provided for connectivity testing, but equivalent Linux commands are missing. The GUI management experience is only available for Windows, with Linux users limited to CLI. Some troubleshooting steps and tool recommendations are Windows-centric, and Linux parity is not always addressed or is relegated to secondary status.

Recommendations:

Provide Linux command equivalents wherever PowerShell or Windows-specific commands are shown (e.g., use 'nc' or 'telnet' for TCP connectivity testing on Linux).
When listing instructions or examples, alternate the order or present both Windows and Linux examples side-by-side to avoid 'windows_first' bias.
Expand troubleshooting guidance to include Linux-native tools and commands (e.g., 'ss', 'netcat', 'dig', 'host' for DNS and connectivity checks).
Clarify GUI limitations for Linux and suggest open-source or CLI alternatives where possible.
Ensure all sections that mention Windows tools or patterns also mention their Linux equivalents, or explicitly state when a feature is unavailable on Linux.
Consider adding a summary table of feature parity between Windows and Linux for Hybrid Connection Manager capabilities.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation demonstrates a Windows bias by providing only PowerShell scripts for advanced resource discovery (e.g., identifying Traffic Manager endpoints), referencing PowerShell as the primary scripting tool, and omitting equivalent Bash or cross-platform CLI script examples. While Azure CLI and REST API commands are mentioned for certificate management, all automation and scripting guidance defaults to PowerShell, which is Windows-centric. There are no Linux shell (Bash) or cross-platform scripting examples, and PowerShell is introduced before or instead of alternatives.

Recommendations:

Provide equivalent Bash (Azure CLI) scripts for all PowerShell automation examples, especially for resource discovery and Traffic Manager endpoint identification.
When referencing scripts, explicitly state if they are cross-platform or provide both Windows (PowerShell) and Linux (Bash) versions.
Instruct users on how to use Azure CLI for all scenarios where PowerShell is currently recommended, ensuring parity for Linux and macOS users.
Where possible, use Azure CLI as the primary example, as it is cross-platform, and mention PowerShell as an alternative.
Review all external script references (e.g., GitHub) and ensure that Linux-compatible versions or instructions are available and linked.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

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

Recommendations:

Include information and examples for discovering .NET web apps hosted on Linux servers, such as those running on Kestrel, Apache, or Nginx.
Describe whether Azure Migrate supports Linux-based .NET app discovery, and if so, provide equivalent instructions and tooling.
Mention Linux environments explicitly in the overview and capabilities sections, or clarify if the feature is Windows-only.
Provide parity in documentation by adding Linux-focused discovery scenarios, error handling, and remediation steps.
Reference Linux tools and patterns where applicable, and ensure that links to further reading include Linux scenarios.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ powershell_heavy

Summary:

The documentation page is heavily biased towards Windows environments. All examples, configuration settings, and troubleshooting steps are specific to Azure App Service on Windows, with exclusive references to Windows tools (IIS, iisnode, web.config, named pipes, Win32 error codes, PowerShell, CMD, etc.). There are no Linux or cross-platform equivalents provided, and Linux-based deployment or troubleshooting is not mentioned.

Recommendations:

Provide parallel documentation or sections for Node.js on Azure App Service for Linux, including configuration, troubleshooting, and best practices.
Include Linux-specific examples (e.g., using PM2, nginx, or Kudu Bash console) alongside or before Windows examples.
Mention Linux equivalents for Windows tools and patterns (e.g., systemd, environment variables, log file locations, error codes).
Avoid assuming the use of web.config, iisnode, or named pipes; instead, describe cross-platform approaches or clearly indicate when a step is Windows-only.
Add links to Linux-focused documentation or guides for Node.js on Azure App Service.
Balance screenshots and walkthroughs between Windows and Linux environments.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a mild Windows bias by referencing Azure Storage Explorer with a direct link to its Windows tab for generating SAS tokens, and by not mentioning or providing Linux-native alternatives for uploading files or generating SAS tokens. All command-line examples use Azure CLI, which is cross-platform, but there are no explicit Linux/macOS instructions or examples for storage management tasks that are shown via Storage Explorer. This may leave Linux users without clear guidance for those steps.

Recommendations:

Provide explicit instructions or examples for uploading files and generating SAS tokens using cross-platform or Linux-native tools, such as the Azure CLI (az storage blob upload, az storage blob generate-sas) or REST API.
Avoid linking directly to Windows-specific tabs or instructions in tool documentation; instead, reference cross-platform guides or clarify that Storage Explorer is available on multiple platforms.
Add a note or section highlighting Linux/macOS workflows for the relevant steps, ensuring parity and clarity for non-Windows users.
If GUI tools are mentioned, also provide equivalent command-line alternatives suitable for headless or Linux environments.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows bias by focusing exclusively on Windows-based deployment and configuration patterns for ASP.NET apps. All runtime version discovery examples use Windows file paths and Kudu's CMD/PowerShell consoles, with no mention of Linux-based App Service environments or their equivalents. There are no Linux-specific instructions or examples, and Windows tools and patterns (such as Visual Studio and web.config) are referenced throughout without Linux parity.

Recommendations:

Add equivalent instructions and examples for Linux-based App Service environments, such as using SSH or Bash in Kudu for Linux.
Include Linux file paths and commands for checking installed .NET runtimes in Linux containers or App Service on Linux.
Clarify which instructions apply only to Windows App Service plans and provide parallel guidance for Linux plans.
Mention and provide examples for deploying and configuring ASP.NET apps using cross-platform tools (e.g., dotnet CLI) where possible.
Reference Linux-specific configuration files or patterns (e.g., appsettings.json for ASP.NET Core on Linux) where appropriate.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation provides both Linux and Windows instructions for configuring Tomcat data sources, but the Windows section is noticeably more detailed, with extensive PowerShell scripting and Windows-specific patterns (e.g., use of startup.cmd, configure.ps1, and %HOME% variables). The Windows instructions are longer, more explicit, and introduce Windows tools and patterns (PowerShell, CMD scripting) that have no direct Linux equivalent in the documentation. While Linux instructions are present and functional, the Windows approach is more thoroughly explained and uses Windows-native tools, which may disadvantage Linux users seeking parity.

Recommendations:

Provide equally detailed, step-by-step Linux instructions for customizing Tomcat, including example shell scripts for startup automation, not just high-level descriptions.
Offer Linux-native equivalents for Windows tools (e.g., show how to automate the server.xml transformation and Tomcat copying using Bash or shell scripts, not just mention 'startup script').
Balance the length and depth of Linux and Windows sections to avoid the impression that Windows is the primary or preferred platform.
Where PowerShell is used for Windows, provide Bash or shell script equivalents for Linux, including error handling and idempotency.
Explicitly mention and link to Linux-specific tools or best practices for managing configuration files and environment variables.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation generally provides parity between Linux and Windows, but there is a subtle Windows bias in several areas. Windows examples and tools (such as Kudu, Advanced Tools, and FTPS) are sometimes mentioned first or exclusively, and some instructions (like using Kudu Process Explorer) are Windows-specific without Linux equivalents. The documentation also refers to Windows-specific behaviors (e.g., web.config, C:\ paths) and tools before or more prominently than Linux alternatives. In a few cases, Linux troubleshooting or deployment patterns are less detailed or referenced only in passing.

Recommendations:

Ensure that for every Windows-specific tool or workflow (e.g., Kudu, Advanced Tools, FTPS), there is a clearly documented Linux equivalent or a note if not applicable.
When listing commands or procedures, alternate the order or present Linux and Windows in parallel tabs to avoid always leading with Windows.
Provide Linux-specific troubleshooting and process management guidance where Windows uses Kudu or other Windows-centric tools.
Review all sections for parity in detail and clarity between Linux and Windows, especially for advanced scenarios (e.g., process management, file downloads, and configuration).
Where a feature is not available or behaves differently on Linux, explicitly state this and suggest alternatives or workarounds.
Avoid referencing Windows file paths (e.g., C:\home) or configuration files (e.g., web.config) without providing the Linux equivalent or clarifying their relevance.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation demonstrates a Windows bias in several ways: examples and templates are primarily focused on ASP.NET and .NET (Windows-centric stacks), Web Deploy (a Windows-only deployment method) is featured with explicit instructions and troubleshooting, and the use of Windows agents is assumed or required for certain deployment scenarios. Linux-specific deployment methods or troubleshooting are not equivalently covered, and Linux is only mentioned in passing (e.g., 'webAppLinux' as an app type), without dedicated examples or guidance for common Linux workflows.

Recommendations:

Provide parallel Linux-focused examples for all deployment scenarios, especially for stacks commonly deployed on Linux (Node.js, Python, Java).
Include troubleshooting sections for Linux agents, not just Windows (e.g., what to do if a deployment fails on Ubuntu agents).
Clearly indicate when a feature or task is Windows-only and offer Linux alternatives where possible (e.g., use of ZIP Deploy or FTP for Linux).
Balance the order of presentation so that Linux and Windows options are given equal prominence, rather than defaulting to Windows-first.
Add explicit examples of deploying to Linux App Service using Linux agents, including YAML snippets and agent pool configuration.
Where Windows tools (like Web Deploy) are discussed, provide equivalent Linux-native deployment methods and their configuration.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation exhibits a Windows-first bias by referencing Windows-style paths (e.g., D:\home\site\wwwroot) before Linux equivalents, and by providing detailed operational instructions (such as directory creation and file placement) only for Windows paths. There is a lack of Linux-specific examples or explicit parity in instructions, and Windows directory conventions are used throughout, with Linux paths mentioned only in passing.

Recommendations:

Provide Linux-specific examples and paths (e.g., /home/site/wwwroot) alongside Windows examples in all relevant sections.
When describing operational steps (such as manually creating directories or files), include both Windows and Linux commands (e.g., mkdir for Windows and Linux).
Ensure that all references to file paths, deployment locations, and troubleshooting steps are presented for both Windows and Linux environments, not just Windows.
Explicitly state any differences in behavior or requirements between Windows and Linux App Service plans.
Add example commands using Bash or other Linux-native tools where appropriate, not just Azure CLI.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation shows a moderate Windows bias, particularly in the .NET/ASP.NET section, where Windows tools (Visual Studio, Azure PowerShell) are listed before cross-platform or Linux-native options. Some quickstart links default to Windows or PowerShell tabs, and Windows-specific tools are mentioned without always providing Linux equivalents. In the Python section, quickstart links include 'windows' in their tab parameters, which may prioritize Windows instructions. The 'Next step' call-to-action also promotes an ASP.NET (typically Windows-centric) workflow.

Recommendations:

Ensure that for every Windows/Powershell example or tool, an equivalent Linux/CLI example is provided and given equal prominence.
Reorder tool lists so that cross-platform or Linux-native tools (e.g., CLI, Visual Studio Code) are mentioned before or alongside Windows-specific tools (e.g., Visual Studio, PowerShell).
Review quickstart links and tab defaults to ensure they do not default to Windows or PowerShell, but rather offer a choice or default to cross-platform instructions.
In the Python section, provide explicit Linux/macOS instructions or clarify that the steps are cross-platform if that is the case.
Balance the 'Next step' call-to-action by offering a Linux-friendly or cross-platform example, not just an ASP.NET (Windows-centric) workflow.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation demonstrates a Windows bias by referencing Visual Studio and its NuGet package manager as the primary method for installing dependencies, with CLI instructions mentioned only as an alternative. There are no explicit Linux or cross-platform development environment examples, and the workflow assumes the use of Windows-centric tools and patterns (e.g., right-clicking folders in Visual Studio). No Linux-specific instructions, screenshots, or terminal commands are provided for common tasks such as file creation, navigation, or deployment.

Recommendations:

Include explicit Linux/macOS instructions for all steps, such as using the dotnet CLI for project/file creation and package installation.
Present CLI-based examples before or alongside Visual Studio/GUI instructions to ensure parity.
Add notes or sections for common Linux development environments (e.g., VS Code, JetBrains Rider, or terminal-only workflows).
Replace or supplement 'right-click' and GUI navigation steps with equivalent command-line instructions (e.g., 'dotnet new page', 'touch OpenAI.razor').
Provide deployment and environment variable configuration steps using Azure CLI and/or ARM templates, not just Azure Portal.
Ensure screenshots and code snippets reflect both Windows and Linux file paths and conventions where relevant.

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 shells (such as Bash, Azure CLI, or REST API). The use of PowerShell cmdlets (New-AzAppServicePlan, Set-AzAppServicePlan, Get-AzWebApp, Set-AzWebApp) assumes a Windows or PowerShell Core environment. There are no examples or guidance for users on Linux or macOS, nor are cross-platform tools mentioned first or at all.

Recommendations:

Add Azure CLI examples for all PowerShell commands, as Azure CLI is cross-platform and widely used on Linux and macOS.
Include Bash shell script examples where appropriate, especially for scripting scenarios.
Mention REST API options for configuring per-app scaling, with example requests.
Present cross-platform (CLI or REST) examples before or alongside PowerShell examples to avoid Windows-first ordering.
Clearly indicate which tools are cross-platform and which are Windows-specific, guiding users to the best option for their OS.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation demonstrates a moderate Windows bias. PowerShell examples are provided alongside Azure CLI, but there are no explicit Linux shell or Bash scripting examples for tasks like retrieving outbound IPs. In the outbound IPv6 section, outbound IPv6 support is noted as available only for Windows apps, with no Linux parity or roadmap mentioned. The ordering of examples often places PowerShell (a Windows-centric tool) before or alongside CLI, but never Bash or Linux-native tools. There are no references to Linux-specific tools or patterns, and some features (outbound IPv6) are Windows-only.

Recommendations:

For every PowerShell example, provide an equivalent Bash/Linux shell example where possible, especially for common tasks like querying IP addresses.
Clarify in the outbound IPv6 section whether Linux support is planned or provide a link to the roadmap.
Where possible, avoid listing PowerShell examples before CLI or Bash, or explicitly note that both Windows and Linux users are supported.
Highlight any feature gaps between Windows and Linux (such as outbound IPv6) and provide workarounds or alternatives for Linux users.
Include troubleshooting or verification steps using Linux-native tools (e.g., dig, host, curl) alongside nslookup and PowerShell.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by referencing Windows-specific paths (e.g., D:\home), tools, and deployment patterns throughout. There are no Linux-specific examples or equivalent Linux paths provided. The only mention of Linux is in the context of unsupported scenarios, and all operational instructions and folder structures are described using Windows conventions. Additionally, tools like Kudu are referenced without mention of KuduLite or Linux alternatives, and the only tool suggested for disk usage is a Windows-centric site extension.

Recommendations:

Include Linux-specific examples and folder paths (e.g., /home/site) alongside Windows paths.
Clarify how local cache works (or does not) on Linux-based App Service plans, and provide parity in operational instructions where possible.
Reference KuduLite and provide instructions or links relevant to Linux App Service environments.
When mentioning tools like 'Azure Web Apps Disk Usage', specify if they are available and how to use them on Linux App Service.
Add a section or callouts for Linux users, even if only to clarify limitations and suggest alternatives (such as App Cache for containers and Linux).

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation provides extensive examples using Azure PowerShell, which is primarily a Windows-centric tool, and does not offer equivalent Bash or Linux shell scripting examples. While Azure CLI is cross-platform, the PowerShell examples are more detailed and prevalent, and there are no explicit Linux/Bash shell command examples for tasks such as token retrieval. This may disadvantage Linux users or those who prefer Bash scripting.

Recommendations:

Add Bash shell scripting examples for token retrieval and other automation tasks, especially in sections where PowerShell scripts are provided.
Clarify that Azure CLI commands are cross-platform and can be run on Linux, macOS, and Windows.
Where PowerShell is used for scripting, provide equivalent Bash (curl/jq) examples to ensure Linux parity.
Explicitly mention and demonstrate how to perform key operations (such as HTTP GET to the local MSI endpoint) using common Linux tools (curl, wget) alongside PowerShell.
Review all code tabs to ensure that Linux users have a clear, first-class path for all documented scenarios.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a subtle Windows bias. Windows-specific features (such as Windows Containers and Windows Server Active Directory) are discussed in detail, with sample calculations and subnet sizing guidance provided only for Windows Containers. There is no equivalent example or detailed guidance for Linux containers or Linux-specific scenarios. Additionally, Windows terminology and tools (e.g., Kudu console, Windows Server AD) are mentioned without Linux alternatives or parity. Linux is only briefly mentioned in the context of continuous deployment network dependencies, and there are no Linux-specific configuration examples or troubleshooting notes.

Recommendations:

Add equivalent subnet sizing and resource planning guidance for Linux containers, including sample calculations.
Provide Linux-specific examples or notes where Windows-specific features are discussed (e.g., mention Linux authentication options when discussing Windows Server AD).
Include references to Linux-native tools or consoles (such as SSH or Bash) alongside mentions of the Kudu console.
Ensure that all configuration and troubleshooting steps are platform-agnostic or provide parallel instructions for both Windows and Linux scenarios.
Where Windows-specific limitations or features are listed, clarify whether they apply to Linux as well, and add Linux-specific limitations if any.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation page exhibits a Windows-first bias in several areas. Windows-specific paths (e.g., D:\home), tools (e.g., msbuild, Web Deploy/MSDeploy), and environment variables are often mentioned before or instead of their Linux equivalents. Some examples and defaults are provided only for Windows (such as time zones and logging), and Windows-specific behaviors are described in more detail. Linux-specific information is sometimes present but often appears as an afterthought or is less detailed. There are also references to Windows tools and patterns (like applicationHost.config, w3wp.exe, and .bat files) without equivalent Linux guidance or examples.

Recommendations:

For every Windows-specific example, provide a Linux equivalent (e.g., show both D:\home and /home paths).
When referencing tools like msbuild or Web Deploy, mention Linux build/deployment tools (e.g., Oryx, Kudu for Linux) and provide parity in explanation.
Avoid using Windows paths or environment variable syntax exclusively in examples; always show both Windows and Linux formats.
When describing settings that behave differently on Windows and Linux, present both behaviors side by side, not with Windows first.
Add Linux-specific troubleshooting and operational guidance where only Windows details are currently given (e.g., for logging, crash monitoring, or startup behaviors).
Review all variable descriptions for implicit Windows assumptions (such as references to .bat files, applicationHost.config, or w3wp.exe) and clarify or supplement with Linux/container equivalents.
Ensure that links to further documentation or references are available for both Windows and Linux scenarios.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows-first bias in several areas: logging types and features are described with Windows as the primary or only platform, with Linux support mentioned secondarily or omitted. Several logging features (web server logging, detailed error messages, failed request tracing) are described as Windows-only, with no Linux equivalents or workarounds provided. Example tools and file paths are often Windows-centric, and some features (like writing application logs to blob storage) are noted as unavailable for non-.NET (and thus often non-Windows) stacks. Linux-specific instructions are minimal and lack parity in detail and options.

Recommendations:

Provide Linux-specific examples and instructions for all logging types, or clearly state feature parity gaps and suggest alternatives.
Where features are Windows-only (e.g., web server logging, detailed error messages, failed request tracing), offer Linux workarounds or third-party tool suggestions.
Include Linux file paths and usage patterns alongside Windows ones in all relevant sections (e.g., log file locations, Kudu usage).
If certain features (like application logging to blob storage) are not supported on Linux, provide code samples or links to community solutions for implementing similar functionality.
Balance the order of presentation: do not always present Windows instructions first; alternate or group by platform.
Expand 'Add log messages in code' with Linux/OSS stack examples (Node.js, Java, PHP, Python) and logging best practices for those environments.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by focusing on Windows-centric tools and patterns, such as IIS diagnostics, PowerShell, and SysInternals Procdump, without providing equivalent Linux guidance. The Kudu Debug Console section highlights PowerShell and DOS commands, and references to diagnostic features (like Application Insights Profiler) are linked specifically to Windows instructions. There are no Linux-specific troubleshooting steps, examples, or mentions of Linux-native tools, despite Azure App Service supporting Linux.

Recommendations:

Add Linux-specific troubleshooting steps and examples, such as using SSH for diagnostics, Linux log file locations, and Linux-native tools (e.g., strace, lsof, top).
When referencing diagnostic features (e.g., Application Insights Profiler), provide links and instructions for both Windows and Linux App Service environments.
In sections mentioning Kudu, clarify the differences in available commands and tools between Windows and Linux App Service plans, and provide Linux shell (bash) examples.
Avoid referencing only Windows tools (e.g., Procdump, IIS logs) without mentioning Linux equivalents or alternatives.
Ensure parity in examples and guidance for both Windows and Linux App Service users throughout the documentation.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a 'windows_first' bias by presenting Windows-specific instructions and examples before Linux equivalents in several sections. It also references Windows-specific tools and directory structures (e.g., 'js-e2e-web-app-easy-auth-app-to-app/frontend' vs 'frontend'), and omits or simplifies Linux-specific guidance in some cases. The Linux instructions are present but sometimes less detailed or appear as an afterthought. There is also a lack of parity in runtime versions and directory navigation between Windows and Linux examples.

Recommendations:

Present Windows and Linux instructions in parallel or in a unified table, rather than always listing Windows first.
Ensure that Linux examples are as detailed and accurate as Windows examples, including directory structure and runtime versions.
Avoid Windows-centric terminology or tools unless absolutely necessary; provide Linux equivalents where possible.
Use neutral language and structure (e.g., 'cd frontend' for both platforms if possible) to reduce perceived bias.
Explicitly call out any platform-specific differences and explain why they exist.
Review and update runtime versions for parity (e.g., use the same Node.js version for both Windows and Linux examples).

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation demonstrates a moderate Windows bias. It references Windows-specific tools (such as SQL Server Management Studio and Visual Studio), provides detailed publishing instructions for Visual Studio before mentioning Git Bash, and omits Linux-native alternatives for some tasks (e.g., connecting to SQL Database with sqlcmd or Azure Data Studio on Linux). There are no explicit PowerShell examples, but the overall workflow assumes a Windows-centric development environment, especially for code publishing and database management.

Recommendations:

Include explicit instructions and examples for Linux users, such as using Azure Data Studio or sqlcmd on Linux for database management.
Provide parity in publishing instructions, giving equal prominence to cross-platform tools (e.g., VS Code, Git CLI) alongside Visual Studio.
Mention and demonstrate Linux-compatible workflows for all steps, including local debugging and deployment.
When referencing tools like SQL Server Management Studio, always mention cross-platform alternatives (e.g., Azure Data Studio) and provide links.
Ensure that all CLI examples are tested and work on both Windows and Linux shells, and clarify any OS-specific prerequisites.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation demonstrates a Windows bias by prioritizing Windows and Visual Studio (Windows) workflows, using PowerShell and Windows-specific tools for critical steps (such as SQLCMD and Package Manager Console), and omitting explicit Linux or cross-platform alternatives for several development and database administration tasks. Linux/macOS development environments are only briefly mentioned, and there are no concrete examples for performing key steps (like database permission grants) from non-Windows systems.

Recommendations:

Provide explicit Linux/macOS equivalents for all PowerShell and Windows-specific steps, especially for database administration (e.g., using sqlcmd or Azure Data CLI on Linux/macOS).
Include examples using cross-platform tools (e.g., Azure CLI, dotnet CLI, VS Code) for all major steps, not just for setup but also for database access and migrations.
Reorder sections or use tabs to present Windows and Linux/macOS instructions with equal prominence, rather than listing Windows/PowerShell first.
Clarify which tools and commands are cross-platform and provide installation or usage notes for Linux/macOS users.
Add troubleshooting or notes for common Linux/macOS issues (e.g., sqlcmd installation, authentication differences).

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

Summary:

The documentation demonstrates a moderate Windows bias, primarily through the use of PowerShell commands and Windows-centric Azure tooling (e.g., AzPowershell, PowerShell@2 tasks) in CI/CD pipeline examples. While the workflows are shown running on Ubuntu agents, the scripts and authentication steps often use PowerShell syntax or Windows-specific tools, and PowerShell-based examples are given before or instead of bash equivalents. There is a lack of explicit Linux shell (bash) or cross-platform CLI alternatives for steps like authentication and dependency installation, which may hinder Linux-first or cross-platform users.

Recommendations:

Provide bash/sh equivalents for all PowerShell commands and scripts, especially for authentication and setup steps.
Show both PowerShell and bash examples side-by-side in CI pipeline YAMLs, or clarify when a step is cross-platform.
Avoid using Windows-specific tooling (like AzPowershell or PowerShell@2) as the default; prefer Azure CLI or cross-platform tools where possible.
Explicitly mention and demonstrate Linux-native workflows, including using bash scripts and Linux package managers.
Ensure that all code snippets and setup instructions are clearly marked as platform-specific, and provide alternatives for Linux/macOS users.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a moderate Windows bias. Visual Studio Code and Azure Portal (both cross-platform but with a strong Windows association) are featured prominently, and there is a lack of explicit Linux/macOS terminal or shell examples. The only shell commands shown are generic (npm, npx, az login), but there are no Linux-specific instructions or screenshots. The Visual Studio Code workflow is described in detail, but alternative editors or CLI-only workflows (common on Linux) are not mentioned. There are no explicit PowerShell commands, but .NET/NUnit (more common on Windows) is given as an alternative runner, and the documentation does not provide parity for Linux-native tools or environments.

Recommendations:

Add explicit Linux/macOS shell examples (e.g., bash/zsh) where environment variables or CLI commands are set, especially for setting environment variables (e.g., export PLAYWRIGHT_SERVICE_URL=...)
Include screenshots or instructions for using the Azure Portal from Linux browsers, or mention that the portal is cross-platform.
Provide parity for Linux-native editors (such as VS Code on Linux, or alternatives like Vim/Emacs) or describe CLI-only workflows for running and debugging Playwright tests.
Clarify that all CLI commands (npm, npx, az) work on Linux/macOS and Windows, and provide any OS-specific caveats if needed.
If mentioning .NET/NUnit, also mention popular Linux test runners or frameworks, or clarify cross-platform support.
Avoid assuming Visual Studio Code as the default editor; mention it as one option among several.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ powershell_heavy

Summary:

The documentation demonstrates a moderate Windows bias. Windows-specific concepts (like registry keys, Windows services, and file paths) are discussed in greater detail and often appear before Linux equivalents. There are extensive tables and examples for Windows registry tracking, but no comparable Linux configuration file or daemon tracking examples. Query and alerting examples focus on Windows paths and registry keys, with only a single Linux daemon example. The documentation also references Windows tools and patterns (e.g., c:\ paths, registry, Windows services) more frequently and in more depth than Linux equivalents.

Recommendations:

Provide Linux-first or parallel Linux examples for all features, especially for configuration tracking (e.g., show how to track changes in /etc/passwd or /etc/ssh/sshd_config, or Linux service files).
Include tables or lists of commonly tracked Linux configuration files and directories, similar to the detailed registry key table for Windows.
Balance query and alerting examples by including Linux-centric scenarios (e.g., tracking changes to /etc/hosts, /etc/systemd/system/*.service, or package installations).
When describing features, alternate the order of Windows and Linux examples, or present them side-by-side.
Expand explanations of Linux daemon and package tracking to match the depth given to Windows services and registry.
Avoid using only Windows-centric terminology (e.g., 'Windows services') without also mentioning Linux equivalents ('Linux daemons') in the same context.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation provides environment variable setup instructions for Windows (cmd and PowerShell) before Linux/macOS, and includes Windows-specific tools (setx, PowerShell syntax) with detailed steps. Linux/macOS instructions are present but consistently listed after Windows, and there are no Linux-specific troubleshooting or parity notes. The CLI example (az login) is cross-platform, but the overall pattern prioritizes Windows users.

Recommendations:

Alternate the order of platform-specific instructions so that Linux/macOS examples are sometimes listed first, or present all platform instructions in a single table for parity.
Provide equal detail for Linux/macOS shell environments (e.g., mention ~/.bashrc or ~/.zshrc for persistent environment variables, not just export).
Avoid using Windows-only tools (like setx) without mentioning Linux/macOS equivalents (e.g., export plus adding to shell profile).
Where possible, use cross-platform commands or highlight them as such.
Add troubleshooting notes for both Windows and Linux/macOS environments to ensure parity.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias by referencing Windows-centric tools and workflows (such as Azurite emulator and Visual Studio Code commands) without clarifying Linux/Mac compatibility or providing alternative instructions. Powershell is included as a primary language, but there are no explicit Bash or Linux shell examples. The instructions for starting Azurite and running the function app assume Visual Studio Code and Windows keybindings, and there is no mention of Linux-specific nuances or terminal commands.

Recommendations:

Explicitly mention that Azurite and Visual Studio Code are cross-platform, and provide instructions for starting Azurite from the command line (e.g., `npx azurite` or `azurite` for Linux/Mac users).
Include Bash or Linux shell equivalents for any Powershell or Windows-specific commands.
Clarify that Visual Studio Code commands and keybindings may differ on Linux/Mac (e.g., <kbd>Cmd</kbd> instead of <kbd>Ctrl</kbd>).
Add a note or section for Linux/Mac users highlighting any differences in setup, file paths, or environment variables.
Where possible, provide terminal-based alternatives to GUI steps (such as using the Azure CLI for resource creation and management).

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation demonstrates a moderate Windows bias. Windows-based build agents ('windows-latest') are used by default or listed first in C# and PowerShell YAML examples, while Linux ('ubuntu-latest') is only used by default for JavaScript and Python. PowerShell is included as a first-class language, but there is no equivalent Bash or shell scripting example for Linux users. The deployment instructions and YAML snippets often default to Windows app types and only mention Linux as an alternative, sometimes as a comment or secondary option. There are no explicit Linux shell scripting or Linux-native tool examples outside of the Python/JavaScript YAML, and the documentation assumes Visual Studio Code as the editor, which is cross-platform but often associated with Windows workflows.

Recommendations:

For each language, provide both Windows and Linux YAML build examples, or clearly indicate parity and differences.
In C# examples, show both 'windows-latest' and 'ubuntu-latest' agent pools, and explain when to use each.
For PowerShell, clarify if Linux PowerShell Core is supported and provide Bash equivalents for packaging/deployment steps.
In deployment sections, present Linux and Windows app deployment YAML side by side, not with Windows as the default.
Explicitly mention Linux-native tools and workflows where possible, and avoid assuming Windows as the default environment.
Add a table or matrix summarizing OS support and recommended agent pools for each language and scenario.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation generally aims for cross-platform parity, but there is a subtle Windows bias. Command-line examples are consistently provided for both Bash (Linux/macOS) and Cmd (Windows), but the Windows/Cmd examples are always listed second, which is positive. However, there is a notable absence of PowerShell-specific examples, which is good. The main bias is that some sections refer to 'command prompt' (a Windows term) alongside 'terminal' and mention Windows in tables before Linux. There are no Linux-specific tools or troubleshooting steps, and some language (e.g., 'open a new command prompt, Bash, or Terminal session') puts Windows terminology first or on equal footing, which can be confusing for Linux users. There are no Linux-only examples or guidance, and the documentation does not mention WSL or other Linux-specific workflows.

Recommendations:

Ensure that references to 'command prompt' are always paired with 'terminal' or 'shell', and consider putting 'terminal' first to reflect cross-platform usage.
Where possible, add Linux-specific troubleshooting tips or notes (e.g., file permissions, environment variable export syntax).
Consider including a short section or callout for WSL users, or for common Linux distributions, to address any OS-specific caveats.
Continue to provide both Bash and Cmd examples, but consider putting Bash (Linux/macOS) first in all cases to reflect the growing popularity of Linux development environments.
Review all language to ensure that Windows-specific terms are not used generically (e.g., use 'terminal' instead of 'command prompt' when referring to any shell).

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation is generally cross-platform and Linux-oriented for hosting, but there are subtle Windows biases in development and publishing workflows. Windows terminology ("command prompt"), tools (Visual Studio Code, Azure Functions Core Tools), and recommendations for remote build when developing on Windows are mentioned before or instead of Linux equivalents. There is also a lack of explicit Linux shell examples, and some folder structure examples use Windows-style command prompt formatting. However, the documentation does clarify that Python Functions are only supported on Linux in Azure, and most content is platform-neutral.

Recommendations:

Provide explicit Linux shell (bash) examples alongside or before Windows command prompt examples, especially for commands like pip install and func azure functionapp publish.
Use neutral terms like 'terminal' or 'shell' instead of 'command prompt' when referring to cross-platform development environments.
Include instructions or notes for Linux/macOS users wherever Windows-specific guidance is given (e.g., Visual Studio Code, Azure Functions Core Tools).
Show folder structure examples using POSIX-style paths (with /) or provide both Windows and Linux versions.
Clarify that all development and deployment steps are fully supported on Linux, and highlight any differences or additional steps required for Linux users.
If recommending remote build for Windows, also explain the equivalent or best practice for Linux/macOS users.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation page demonstrates a moderate Windows bias, particularly in its developer guidance and command-line tooling. PowerShell is referenced prominently, with a dedicated note about the Azure PowerShell Az module and its installation, and PowerShell examples are provided alongside Azure CLI. The PowerShell example is given equal or slightly greater prominence than the Azure CLI example, and there is no mention of Bash, Linux shells, or Linux-specific tooling. Additionally, references to Visual Studio and System Center Operations Manager further reinforce a Windows-centric perspective.

Recommendations:

Include explicit Bash/Linux shell examples for all command-line instructions, especially where Azure CLI is used.
When referencing PowerShell, ensure that equivalent Linux/Bash commands are provided and shown first or side-by-side.
Mention cross-platform compatibility of Azure CLI and PowerShell Core (pwsh) to clarify usage on Linux and macOS.
Add guidance for using non-Windows developer tools (e.g., VS Code, JetBrains Rider) in relevant sections.
Avoid assuming Visual Studio or Windows-only tools; provide alternatives or clarify when a tool is cross-platform.
Where possible, use neutral language such as 'command-line' or 'shell' instead of 'PowerShell' unless specifically required.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows bias by providing detailed PowerShell instructions and commands for connecting to Azure Government, while omitting equivalent Linux/Unix shell or scripting examples. The CLI section is present and cross-platform, but PowerShell is highlighted with multiple connection types and commands, and there are no Bash or Linux-specific instructions. The 'Next steps' section also points to PowerShell-specific resources. There is no mention of Linux tools, nor are Linux/Unix patterns or examples provided alongside or before Windows/PowerShell ones.

Recommendations:

Add Bash or Linux shell examples for connecting to Azure Government and using Azure NetApp Files, especially in sections where PowerShell commands are provided.
Include explicit notes or sections for Linux/macOS users, clarifying any differences or additional steps required.
Balance the prominence of PowerShell and Windows tools by providing parallel instructions for cross-platform tools (e.g., Azure CLI, REST API via curl, or SDK usage in Python).
In the 'Next steps' section, include links to Linux- or cross-platform-focused resources, not just PowerShell.
Where possible, present cross-platform or Linux examples before or alongside Windows/PowerShell examples to avoid the perception of Windows-first bias.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows bias by providing only Windows-based instructions and tools for managing SMB volume access and permissions. All examples and management steps reference Windows interfaces (MMC, Control Panel, Windows SMB client), with no mention of Linux or cross-platform alternatives for accessing or managing SMB shares. There are no Linux command-line examples or references to Linux SMB clients (such as smbclient or mount.cifs), and the documentation assumes a Windows administrative environment.

Recommendations:

Include instructions and examples for accessing and managing SMB volumes from Linux clients, such as using smbclient, mount.cifs, or GNOME/KDE file managers.
Provide Linux command-line examples for mounting SMB shares and setting permissions (where possible, e.g., using setfacl or mount options).
Mention cross-platform SMB management tools and clarify which features are available or limited on non-Windows clients.
Reorganize sections to present both Windows and Linux management options in parallel, rather than focusing exclusively on Windows.
Add troubleshooting tips for common Linux SMB client issues (e.g., authentication, permissions, mount options).

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

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

Recommendations:

Explicitly mention support for assessing .NET web apps running on Linux, if applicable.
Include examples or references for assessing .NET Core or ASP.NET Core apps hosted on Linux.
Reference or link to Linux-compatible tools and command-line instructions (e.g., Bash, CLI) alongside any Windows/Powershell tools.
Clarify whether the assessment process or tools differ for Linux-hosted apps and provide guidance accordingly.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation exhibits a Windows-first bias by referencing the Windows deployment path (C:\home\site\wwwroot) and providing a detailed note about path differences, but only gives a concrete example for Windows (relative path) and not for Linux. The Linux path is mentioned only in a note, and there are no Linux-specific examples or commands. No Linux tools or patterns are discussed, and the default pathing and instructions assume familiarity with Windows conventions.

Recommendations:

Provide Linux-specific examples alongside Windows examples, such as using '/home/site/wwwroot/auth.json' in the main instructions, not just in a note.
When mentioning file paths, always show both Windows and Linux variants together (e.g., 'C:\home\site\wwwroot\auth.json' (Windows) and '/home/site/wwwroot/auth.json' (Linux)).
Clarify any differences in file deployment or permissions between Windows and Linux App Service environments.
Include Linux command-line examples (e.g., using bash or Linux-native tools) where relevant.
Avoid assuming Windows as the default; use neutral language or parallel examples for both platforms.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation demonstrates a bias toward Windows by exclusively referencing the Azure portal GUI workflow, which is more commonly used and accessible on Windows environments. There are no command-line examples (such as Azure CLI or PowerShell), nor are there any Linux-specific instructions or considerations. This omission may disadvantage Linux users who prefer or require CLI-based configuration or who do not use the Azure portal's graphical interface.

Recommendations:

Add equivalent instructions using the Azure CLI for all configuration steps, ensuring that Linux and macOS users can follow along without relying on the Azure portal GUI.
Include examples or notes for configuring authentication via ARM templates or Bicep, which are platform-agnostic.
If PowerShell examples are added, ensure that Bash or shell equivalents are also provided.
Explicitly mention that all steps can be performed on any OS, or provide OS-specific guidance where relevant.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation presents Windows container SSH access first and in more favorable terms, stating that no modifications are required for Windows custom containers, while Linux custom containers require extra configuration. The Windows section lacks command-line or PowerShell examples, but the Linux section provides detailed Azure CLI and SSH command instructions. There are no equivalent command-line instructions or troubleshooting steps for Windows containers, and the Linux section is more comprehensive overall.

Recommendations:

Provide parity in example depth: Add command-line or PowerShell instructions for connecting to Windows containers, or explicitly state if such access is not supported.
Clarify feature differences: Clearly explain any limitations or differences in SSH support between Linux and Windows containers, including why Azure CLI is not supported for Windows.
Balance order and emphasis: Present Linux and Windows instructions in parallel or clarify why one is presented before the other.
Add troubleshooting and usage examples for Windows: If possible, include example usage, troubleshooting, and expected output for Windows containers, similar to the Linux section.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation assumes a development environment that is either Windows-based or at least not explicitly Linux-friendly. It references GitHub Codespaces (which is cross-platform) but does not provide any explicit Linux shell commands, nor does it mention Linux-specific tools or workflows. All terminal commands are given in a generic way, but there is no mention of Linux package managers, shell differences, or deployment nuances for Linux users. There are no PowerShell-specific commands, but the lack of Linux-specific guidance or examples (such as using bash, apt, or Linux file paths) indicates a subtle Windows-first bias.

Recommendations:

Explicitly mention that the tutorial works on both Windows and Linux, and clarify any OS-specific prerequisites.
Provide Linux-specific instructions or notes where relevant (e.g., using bash instead of cmd/PowerShell, Linux file paths, or package installation).
Include screenshots or terminal output from both Windows and Linux environments to demonstrate parity.
If using Codespaces, clarify that it is a Linux container by default and note any differences for local Windows or Linux development.
Mention any OS-specific dependencies or troubleshooting steps that may be needed for Linux users.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation demonstrates environment-based configuration using ASP.NET Core and Azure App Configuration, but it assumes the use of Visual Studio-style project structures (e.g., launchSettings.json) and does not provide any Linux-specific instructions or examples. There are no mentions of Linux tools, environment variable setting patterns, or cross-platform considerations. The only method shown for setting environment variables is via launchSettings.json, which is primarily used in Windows/Visual Studio development environments.

Recommendations:

Include instructions for setting environment variables on Linux/macOS, such as using export in the terminal or setting variables inline with the dotnet run command.
Mention alternative ways to run and configure the application outside of Visual Studio, such as from the command line or in Docker containers.
Add a note clarifying that launchSettings.json is not used when running dotnet applications outside of Visual Studio or Visual Studio Code, and provide equivalent steps for Linux users.
Provide example commands for building and running the application on Linux/macOS, and explain how to set ASPNETCORE_ENVIRONMENT in those environments.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page provides an example for retrieving the system key using the Azure CLI, which is cross-platform, but does not include any Linux- or macOS-specific shell examples (such as bash or zsh). There are no explicit Windows-only tools or PowerShell commands, but the absence of Linux/macOS terminal examples and the lack of explicit mention of Linux environments may make the documentation feel Windows-centric. Additionally, there is no mention of Linux-specific installation or troubleshooting steps, nor any explicit parity checks for Linux users.

Recommendations:

Include explicit bash/zsh shell examples alongside Azure CLI commands, demonstrating usage in Linux/macOS terminals.
Mention that Azure CLI works on Windows, Linux, and macOS, and provide links to installation instructions for each OS.
If there are any OS-specific considerations (such as file paths, environment variables, or permissions), document them for both Windows and Linux/macOS.
Add troubleshooting notes or tips for common issues encountered on Linux (e.g., permissions, dependency installation, or differences in local development environments).
Ensure that all code snippets and instructions are validated on both Windows and Linux/macOS platforms.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation page exhibits a mild Windows bias by referencing Windows-specific documentation and tools before or instead of Linux equivalents. Specifically, the link for creating a Proximity Placement Group (PPG) directs users to a Windows Virtual Machines portal guide, and there are no explicit Linux or cross-platform examples or references. However, the overall content is largely platform-neutral, focusing on Azure concepts rather than OS-specific commands or scripts.

Recommendations:

Provide links to both Windows and Linux documentation for tasks like creating Proximity Placement Groups (e.g., include /azure/virtual-machines/linux/proximity-placement-groups-portal alongside the Windows link).
Where examples or references to VM management are given, clarify that the guidance applies to both Windows and Linux VMs, or provide parallel instructions/examples for both platforms.
Review all linked resources to ensure Linux users are equally supported, especially in cross-platform SAP HANA deployments.
Explicitly mention that the described procedures are applicable to both Windows and Linux SAP HANA deployments, unless there are platform-specific differences.

Create pull request

Bias Types:

⚠️ missing_linux_example

Summary:

The documentation provides configuration and usage examples for Playwright Workspaces using TypeScript (Node.js) and C# (NUnit), but does not include any Linux- or Unix-specific instructions, shell commands, or references to Linux tools or environments. There are no explicit Windows-only commands, but the absence of Linux-specific guidance or troubleshooting may disadvantage Linux users.

Recommendations:

Add explicit Linux/Unix shell command examples where relevant, such as using bash/zsh or common Linux CLI patterns.
Include notes or troubleshooting tips for Linux users, such as handling permissions, networking, or environment variables that may differ from Windows.
If any platform-specific configuration is required (e.g., file paths, environment setup), provide both Windows and Linux examples.
Clarify that the provided commands (npx, dotnet) are cross-platform, and mention any prerequisites or differences for Linux environments.
Consider adding a section or callout confirming Linux support and linking to Linux-specific Playwright documentation if available.

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation page lists .NET and ASP.NET Core provider libraries first, with their samples and release notes, before Java, Python, JavaScript, and Go equivalents. This ordering implicitly prioritizes Windows-centric technologies (especially .NET/ASP.NET) over Linux-native or cross-platform stacks, despite the cross-platform nature of Azure App Configuration. However, there are no explicit Windows-only tools, PowerShell examples, or missing Linux examples; all samples are language/platform-specific and not OS-specific.

Recommendations:

Reorder the provider libraries table to alternate or group by language family (e.g., JVM, .NET, scripting) or by popularity, rather than listing all .NET/Windows-centric libraries first.
Add a clarifying note that all listed libraries are cross-platform unless otherwise specified, and that .NET Core and ASP.NET Core are supported on Linux and macOS as well as Windows.
Consider including explicit Linux/macOS usage notes or examples where relevant, especially for .NET Core and ASP.NET Core, to reinforce cross-platform support.
If possible, provide a section or table that highlights OS compatibility for each provider, making it clear that Windows is not a prerequisite.

Create pull request

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