← Back to Dashboard
246
Pages Scanned
42
Pages Flagged
246
Changed Pages
17.1%
% Pages Flagged

Scan Information

Started At: 2026-02-03 00:00:08

Finished At: 2026-02-10 18:44:36

Status: completed

Target Repo: Azure

Current Phase: discovery

Files Queued: 246

Files Completed: 246

Problematic Pages

42 issues found
Azure Relay https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-relay/includes/relay-hybrid-connections-dotnet-get-started-server.md ...https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-relay/includes/relay-hybrid-connections-dotnet-get-started-server.md
High Priority View Details →
Reviewed by: LLM Analysis
Issues: 2 bias types
Detected Bias Types
⚠️ windows_first ⚠️ missing_linux_example
Summary
The documentation instructs users to create a .NET Framework console application using Visual Studio, which is a Windows-only IDE and targets the Windows-only .NET Framework. There are no instructions or examples for Linux/macOS users, such as using .NET Core/.NET 5+ or cross-platform development tools (e.g., VS Code, CLI). This creates friction for non-Windows users who wish to use Azure Relay with .NET.
Recommendations
  • Add instructions for creating a cross-platform .NET (Core/5+) console application using the dotnet CLI or Visual Studio Code.
  • Clarify whether the Microsoft.Azure.Relay NuGet package supports .NET Core/.NET 5+ and provide relevant code samples.
  • If the feature is not Windows-only, include Linux/macOS setup steps and examples.
  • Explicitly state platform requirements and alternatives for non-Windows users.
GitHub Create Pull Request
Artifact Signing Set up signing integrations to use Artifact Signing ...ticles/artifact-signing/how-to-signing-integrations.md
High Priority View Details →
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
⚠️ windows_tools ⚠️ powershell_heavy ⚠️ windows_first ⚠️ missing_linux_example
Summary
The documentation for setting up signing integrations with Artifact Signing is heavily Windows-centric, especially in the SignTool section. All setup instructions, prerequisites, and examples are tailored for Windows environments, using Windows-specific tools (SignTool.exe, MSI installers, WinGet, PowerShell). There are no equivalent instructions or examples for Linux or macOS users, nor is there guidance for cross-platform alternatives. The other integrations (GitHub Actions, Azure DevOps, SDK) are mentioned but not documented in detail here.
Recommendations
  • Add explicit guidance for Linux/macOS users, including supported signing tools and setup steps.
  • If SignTool is Windows-only, clarify this early and direct non-Windows users to alternative integrations (e.g., SDK, GitHub Actions).
  • Provide examples for using Artifact Signing with cross-platform tools (e.g., OpenSSL, sigstore, or .NET CLI on Linux/macOS if supported).
  • Ensure parity in documentation for SDK usage, including Linux/macOS installation and usage instructions.
  • Where PowerShell is used for automation, offer equivalent Bash or shell script examples for Linux/macOS.
GitHub Create Pull Request
Application Gateway Diagnostic logs ...application-gateway/application-gateway-diagnostics.md
Medium Priority View Details →
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
⚠️ powershell_heavy ⚠️ missing_linux_example ⚠️ windows_tools
Summary
The documentation provides a PowerShell-only example for enabling diagnostic logging, with no equivalent CLI, Bash, or Azure CLI instructions. The log converter tool referenced is a .NET/C# solution, which is more Windows-centric. There is no mention of Linux/macOS command-line workflows or tools, and PowerShell is presented as the sole scripting method for automation.
Recommendations
  • Add equivalent Azure CLI (az) commands for enabling diagnostic logging, as Azure CLI is cross-platform and widely used on Linux/macOS.
  • Include Bash or shell script examples for common log management tasks, such as downloading and converting logs.
  • Reference or provide log converter tools that run natively on Linux/macOS (e.g., Python-based solutions), or clarify cross-platform usage of the existing .NET tool.
  • Explicitly state that PowerShell examples are also available on Linux/macOS (if true), or link to cross-platform PowerShell installation guides.
GitHub Create Pull Request
Automation Azure Automation data security ...b/main/articles/automation/automation-managing-data.md
Medium Priority View Details →
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
⚠️ windows_first ⚠️ powershell_heavy ⚠️ missing_linux_example
Summary
The documentation provides both Windows and Linux guidance for TLS configuration, but Windows/PowerShell tools and examples are mentioned first and more frequently throughout the page. Several backup and data management tasks reference only PowerShell cmdlets, with no equivalent CLI or Linux-native examples provided. Linux guidance is present for TLS but is less detailed elsewhere.
Recommendations
  • For every PowerShell cmdlet example (e.g., Unregister-AzAutomationDscNode, Get-AzAutomationRunbookContent, Export-AzAutomationDscConfiguration), provide equivalent Azure CLI or REST API examples that work cross-platform.
  • When listing platform-specific instructions or tables, alternate the order or present Linux and Windows guidance in parallel to avoid a 'Windows-first' impression.
  • Expand Linux guidance beyond TLS—for example, explain how to unregister DSC nodes, export runbooks, or manage assets using cross-platform tools.
  • Where only PowerShell is supported, explicitly state this and, if possible, link to feature requests or workarounds for Linux/macOS users.
GitHub Create Pull Request
API Center Quickstart - Create Your Azure API Center - ARM Template .../articles/api-center/set-up-api-center-arm-template.md
Medium Priority View Details →
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
⚠️ windows_first ⚠️ powershell_heavy ⚠️ missing_linux_example
Summary
The documentation provides both Azure CLI and Azure PowerShell examples for deploying the ARM template, but PowerShell is given equal prominence to CLI and is mentioned in metadata and prerequisites. There are no explicit Linux/macOS shell examples (e.g., Bash), and the instructions for uploading the template file reference Azure Cloud Shell generically, without clarifying Linux/macOS workflows. The documentation does not mention Linux-specific tools or patterns, and PowerShell is not clearly marked as Windows-only, which may cause confusion for Linux/macOS users.
Recommendations
  • Add explicit Bash shell examples for deploying ARM templates using Azure CLI on Linux/macOS.
  • Clarify that Azure PowerShell is available cross-platform, but most Linux/macOS users will prefer Azure CLI.
  • Provide instructions for uploading files in Linux/macOS environments (e.g., using scp, curl, or direct download in Cloud Shell).
  • Ensure that CLI examples are shown first, as they are more universally applicable.
GitHub Create Pull Request
App Service Install a TLS/SSL Certificate for Your App ...main/articles/app-service/configure-ssl-certificate.md
Medium Priority View Details →
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
⚠️ windows_tools ⚠️ windows_first ⚠️ powershell_heavy
Summary
The documentation provides both Azure CLI and Azure PowerShell examples for assigning Key Vault permissions, but PowerShell is given equal or slightly more prominence in some sections. In the certificate export section, Windows-specific tools (IIS, Certreq.exe) are mentioned for exporting certificates, with only a brief reference to OpenSSL for Linux/macOS. The FAQ and automation sections link to both CLI and PowerShell scripts, but PowerShell is often mentioned first. There are no Linux/macOS-specific screenshots or portal instructions, and the overall flow assumes familiarity with Windows-centric tools and patterns.
Recommendations
  • Ensure that for every PowerShell example, an Azure CLI (cross-platform) equivalent is provided and shown first, or at least in parallel.
  • In sections about exporting certificates, provide explicit OpenSSL commands and workflows for Linux/macOS, not just a passing mention.
  • Where Windows tools like IIS or Certreq.exe are referenced, add clear alternatives for Linux/macOS users (e.g., OpenSSL commands for generating and exporting certificates).
  • Include notes or screenshots that clarify any UI differences for Linux/macOS users, if applicable.
  • In automation and FAQ sections, list Azure CLI (cross-platform) scripts before PowerShell scripts to reduce perceived Windows-first bias.
GitHub Create Pull Request
App Service Use TLS/SSL Certificates in App Code ...icles/app-service/configure-ssl-certificate-in-code.md
Medium Priority View Details →
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
⚠️ windows_first ⚠️ powershell_heavy ⚠️ missing_linux_example ⚠️ windows_tools
Summary
The documentation page provides detailed, step-by-step code examples for accessing certificates in Windows environments (including Windows apps and containers), with C# and Java code focused on the Windows certificate store. Linux guidance is limited to C# file-based loading, with no equivalent code samples for other languages (Node.js, PHP, Python, Java) on Linux. Windows-specific tools and patterns (certificate store, thumbprint usage, environment variables) are described in detail before Linux equivalents, and Windows examples are generally presented first or exclusively.
Recommendations
  • Provide equivalent, detailed code examples for Linux environments, especially for popular languages such as Node.js, Python, Java, and PHP.
  • Present Linux and Windows guidance in parallel, or use tabs to avoid Windows-first ordering.
  • Add explicit instructions or code samples for accessing certificates in Linux containers for languages other than C#.
  • Clarify when Windows-specific features (like the certificate store) are not available or relevant on Linux, and offer Linux-native alternatives.
  • Reference Linux tools and patterns (such as OpenSSL, PEM/PFX file handling) where appropriate.
GitHub Create Pull Request
Application Gateway Scaling and Zone-redundant Application Gateway v2 ...eway/application-gateway-autoscaling-zone-redundant.md
Medium Priority View Details →
Reviewed by: LLM Analysis
Issues: 2 bias types
Detected Bias Types
⚠️ powershell_heavy ⚠️ windows_first
Summary
The documentation page provides a link to a tutorial for creating an autoscaling, zone-redundant Application Gateway using Azure PowerShell, without mentioning or linking to equivalent instructions for Azure CLI, ARM templates, or Bicep. Azure PowerShell is most commonly used on Windows, and its exclusive mention may create friction for Linux/macOS users who typically use Azure CLI or other cross-platform tools.
Recommendations
  • Add links or examples for creating autoscaling, zone-redundant Application Gateway using Azure CLI, ARM templates, or Bicep.
  • Ensure that cross-platform tools are mentioned alongside PowerShell, or provide a section comparing approaches for different operating systems.
  • In 'Next steps', include tutorials for Linux/macOS users or clarify that PowerShell can be used cross-platform (with installation instructions if necessary).
GitHub Create Pull Request
Application Gateway Migrate from V1 to V2 - Azure Application Gateway ...lob/main/articles/application-gateway/migrate-v1-v2.md
Medium Priority View Details →
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
⚠️ powershell_heavy ⚠️ missing_linux_example ⚠️ windows_tools
Summary
The documentation for migrating Azure Application Gateway from V1 to V2 is heavily focused on Azure PowerShell scripts and cmdlets, with all examples, instructions, and tooling based on PowerShell. There are no equivalent examples or guidance for Linux/macOS users who may prefer Bash, Azure CLI, or scripting in other environments. The documentation assumes the use of PowerShell and Windows-centric patterns throughout, which may create friction for users on non-Windows platforms.
Recommendations
  • Provide equivalent Azure CLI (az) examples for all migration steps, including resource ID retrieval, certificate management, and script execution.
  • Clarify that Azure Cloud Shell supports both Bash and PowerShell, and offer Bash/CLI instructions for users who choose that environment.
  • Explicitly mention cross-platform compatibility of the provided PowerShell scripts, or offer alternative scripts in Bash or Python if possible.
  • Add a section addressing Linux/macOS users, including prerequisites and environment setup for running migration scripts.
  • Where PowerShell is required, note how to install and run PowerShell Core on Linux/macOS, and test scripts for compatibility.
GitHub Create Pull Request
Application Gateway FAQ on V1 retirement ...ob/main/articles/application-gateway/retirement-faq.md
Medium Priority View Details →
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
⚠️ powershell_heavy ⚠️ windows_tools ⚠️ missing_linux_example
Summary
The documentation page on Application Gateway V1 retirement and migration to V2 heavily references Azure PowerShell scripts as the primary migration tooling, with no mention of equivalent Azure CLI or ARM template approaches. All example scripts and automation guidance are PowerShell-based, which is most commonly used on Windows. There are no Linux/macOS-specific instructions or examples, and no guidance for users who may prefer or require cross-platform tools.
Recommendations
  • Add equivalent Azure CLI commands and scripts for migration tasks, including public IP retention and configuration migration.
  • Explicitly mention that Azure CLI can be used on Linux/macOS and provide links or examples.
  • Clarify whether ARM templates or REST API can be used for migration, and provide sample templates or API calls if possible.
  • Where PowerShell scripts are referenced, note any cross-platform compatibility (e.g., PowerShell Core on Linux/macOS) or provide alternatives.
  • Ensure that troubleshooting and support instructions do not assume Windows/PowerShell usage only.
GitHub Create Pull Request
App Service Environment Variables and App Settings Reference ...ob/main/articles/app-service/reference-app-settings.md
Medium Priority View Details →
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
⚠️ windows_first ⚠️ windows_tools ⚠️ powershell_heavy
Summary
The documentation generally covers both Windows and Linux, but there is a recurring pattern of Windows-centric terminology, examples, and environment variable values being shown first or exclusively. Several variables and descriptions reference Windows paths (e.g., D:\home), Windows-specific tools (e.g., msbuild, Web Deploy/MSDeploy), and Windows configuration files (e.g., applicationHost.config, Web.config) without always providing Linux equivalents or parity in explanation. Some sections (such as Build Automation) give more detail for Windows (Kudu) than Linux (Oryx), and Windows tools are often mentioned before Linux alternatives.
Recommendations
  • For every environment variable or feature that behaves differently on Windows and Linux, provide both examples and clarify the differences explicitly.
  • When referencing paths, always show both Windows and Linux equivalents (e.g., D:\home and /home).
  • When mentioning Windows-specific tools (e.g., msbuild, Web Deploy), also mention Linux equivalents or note when no equivalent exists.
  • In tables and lists, alternate or parallelize the order of Windows and Linux information, rather than consistently listing Windows first.
  • Expand the Oryx (Linux) build automation section to match the detail level of the Kudu (Windows) section.
  • Where features are Windows-only, clearly label them as such to avoid confusion.
GitHub Create Pull Request
Application Gateway What is Azure Application Gateway v2? .../blob/main/articles/application-gateway/overview-v2.md
Medium Priority View Details →
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
⚠️ powershell_heavy ⚠️ windows_tools ⚠️ missing_linux_example
Summary
The documentation page for Azure Application Gateway v2 shows a notable bias toward Windows/PowerShell tooling. Migration and preview registration/unregistration instructions are provided exclusively using Azure PowerShell cmdlets, with no mention of Azure CLI (bash/zsh) or ARM template alternatives. The main tutorial linked is PowerShell-based, and there are no Linux/macOS-specific examples or guidance. This creates friction for users on non-Windows platforms who may prefer or require cross-platform tools.
Recommendations
  • Provide equivalent Azure CLI (bash/zsh) commands for all PowerShell instructions, especially for migration and preview registration/unregistration.
  • Link to or create tutorials using Azure CLI and ARM templates for creating and managing Application Gateway v2.
  • When referencing scripts or automation, clarify platform compatibility and offer alternatives for Linux/macOS users.
  • Ensure that examples and walkthroughs are not exclusively PowerShell-based, and consider showing CLI examples first or side-by-side.
GitHub Create Pull Request
Application Gateway Tutorial: Improve web application access - Azure Application Gateway .../articles/application-gateway/tutorial-autoscale-ps.md
Medium Priority View Details →
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
⚠️ powershell_heavy ⚠️ windows_tools ⚠️ missing_linux_example
Summary
The tutorial exclusively uses Azure PowerShell and Windows PowerShell cmdlets for all steps, including certificate creation and resource management. There are no Bash, Azure CLI, or Linux/macOS-specific instructions or examples. Windows tools (e.g., New-SelfSignedCertificate, Export-PfxCertificate) are used for certificate creation, which are not available on Linux/macOS. This creates friction for non-Windows users, who must find alternative methods to complete key steps.
Recommendations
  • Provide equivalent Azure CLI (az) commands for all resource management steps, as Azure CLI is cross-platform.
  • Include instructions for creating self-signed certificates on Linux/macOS (e.g., using OpenSSL) and exporting to PFX format.
  • Add notes or links for Linux/macOS users on how to adapt PowerShell-specific steps, or reference cross-platform PowerShell (pwsh) usage.
  • Consider reordering examples so that cross-platform methods (Azure CLI, OpenSSL) are shown first or alongside PowerShell.
GitHub Create Pull Request
Automation Configure runbook input parameters in Azure Automation ...b/main/articles/automation/runbook-input-parameters.md
Medium Priority View Details →
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
⚠️ powershell_heavy ⚠️ windows_first ⚠️ missing_linux_example ⚠️ windows_tools
Summary
The documentation page for configuring runbook input parameters in Azure Automation exhibits a notable Windows/PowerShell bias. Most examples, code snippets, and workflows are based on PowerShell, PowerShell Workflow, or graphical runbooks (which are PowerShell-based). The only Linux-relevant section is for Python runbooks, which is brief and lacks parity in depth and example coverage compared to PowerShell. All command-line examples for starting runbooks use PowerShell cmdlets, with no mention of Bash, Azure CLI, or Linux-native tooling. The JSON passing example is exclusively PowerShell-based, and SDK examples use C#, which is more common in Windows environments. There is no guidance for Linux/macOS users on how to interact with runbooks using Azure CLI or Bash scripts.
Recommendations
  • Add equivalent Azure CLI examples for starting runbooks and passing parameters, including JSON objects.
  • Provide Bash script examples for interacting with the Azure Automation REST API.
  • Expand the Python runbook section with more detailed parameter handling examples, including complex types and best practices.
  • Clarify which features or examples are platform-agnostic and which are PowerShell/Windows-specific.
  • Include notes or links for Linux/macOS users on how to install and use Azure CLI and Python for Azure Automation tasks.
GitHub Create Pull Request
Automation Manage credentials in Azure Automation ...in/articles/automation/shared-resources/credentials.md
Medium Priority View Details →
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
⚠️ powershell_heavy ⚠️ windows_tools ⚠️ windows_first
Summary
The documentation is heavily focused on PowerShell and Windows-centric tools and patterns. All CLI examples are in PowerShell, and cmdlet usage is described exclusively in terms of PowerShell modules and objects (e.g., PSCredential). The only non-PowerShell examples are for Python runbooks, but there are no Bash, Azure CLI, or cross-platform shell examples. The section on creating credentials via CLI only covers Windows PowerShell, and PowerShell terminology is used throughout, even when discussing general credential management.
Recommendations
  • Add Azure CLI examples for credential management tasks (creation, retrieval, deletion) where possible.
  • Clarify if credential management via CLI is only possible with PowerShell, or document Linux/macOS-compatible alternatives.
  • If PowerShell Core (pwsh) is supported on Linux/macOS, explicitly mention this and provide examples.
  • Reorganize sections so that cross-platform or portal-based methods are presented before Windows-specific PowerShell methods.
  • Explicitly state any limitations for non-Windows users and provide guidance or workarounds.
GitHub Create Pull Request
Automation Disaster recovery for Azure Automation ...in/articles/automation/automation-disaster-recovery.md
Medium Priority View Details →
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
⚠️ powershell_heavy ⚠️ missing_linux_example ⚠️ windows_first
Summary
The documentation for disaster recovery in Azure Automation is heavily focused on PowerShell scripts and workflows, with no mention or examples of Bash, Python, or other Linux-native scripting options. All migration instructions and runbook examples are provided using PowerShell, and tabs for script installation reference Windows first. While the documentation states applicability to both Linux and Windows VMs, Linux users may find it difficult to follow or replicate the migration process without PowerShell or Windows environments.
Recommendations
  • Provide equivalent migration scripts or runbook examples using Bash or Python, which can run natively on Linux.
  • Clarify if PowerShell Core (pwsh) is supported and provide instructions for Linux/macOS environments.
  • Include explicit steps or notes for Linux users on how to execute migration tasks without requiring Windows or PowerShell Desktop.
  • Add examples or references for Linux tools and workflows where applicable, such as az CLI or ARM template deployment via Bash.
GitHub Create Pull Request
Automation Use Microsoft Entra ID in Azure Automation to authenticate to Azure ...ob/main/articles/automation/automation-use-azure-ad.md
Medium Priority View Details →
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
⚠️ powershell_heavy ⚠️ windows_tools ⚠️ missing_linux_example ⚠️ windows_first
Summary
The documentation is heavily focused on PowerShell and Windows-centric tooling, such as PSCredential, Get-AutomationPSCredential, and Windows PowerShell modules. All code examples and instructions use PowerShell, with no mention of Bash, CLI, or Linux/macOS alternatives. Windows terminology and tools are referenced first and exclusively, which may create friction for Linux/macOS users who wish to use Azure Automation with Microsoft Entra ID.
Recommendations
  • Add equivalent examples using Azure CLI and Bash for credential management and runbook automation.
  • Clarify which steps are platform-agnostic and which are Windows/PowerShell-specific.
  • Provide guidance or links for Linux/macOS users on how to authenticate to Azure Automation using Microsoft Entra ID.
  • Mention cross-platform alternatives to PSCredential and PowerShell modules where possible.
  • Explicitly state if PowerShell is required for certain features, and suggest installation steps for PowerShell Core on Linux/macOS if relevant.
GitHub Create Pull Request
Automation Manage certificates in Azure Automation ...n/articles/automation/shared-resources/certificates.md
Medium Priority View Details →
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
⚠️ powershell_heavy ⚠️ windows_tools ⚠️ windows_first
Summary
The documentation page for managing certificates in Azure Automation demonstrates a notable Windows/PowerShell bias. PowerShell cmdlets are emphasized throughout, with detailed examples and workarounds provided for PowerShell users (including recommendations to use PowerShell when the portal fails for CSP accounts). The creation and management of certificates are described almost exclusively via PowerShell, and Windows-centric cryptographic provider requirements are mentioned. While Python examples are included for runbooks, there are no Linux shell (bash/CLI) examples, nor is there guidance for Linux/macOS users on certificate creation or management outside PowerShell. The documentation assumes familiarity with Windows tools and patterns, and PowerShell examples are presented before Python ones.
Recommendations
  • Add Azure CLI examples for certificate management tasks, especially for creation and retrieval.
  • Include guidance or examples for Linux/macOS users on preparing and uploading certificates (e.g., using OpenSSL to generate .pfx/.cer files).
  • Clarify whether PowerShell cmdlets must be run on Windows, or if cross-platform PowerShell Core is supported.
  • Mention any platform-specific limitations or requirements for certificate provider compatibility.
  • Present Python and CLI examples alongside PowerShell, not only after.
GitHub Create Pull Request
Azure Change Tracking Inventory Azure Change Tracking and Inventory Overview by Using Azure Monitor Agent ...change-tracking-inventory/overview-monitoring-agent.md
Medium Priority View Details →
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
⚠️ windows_first ⚠️ windows_tools ⚠️ missing_linux_example
Summary
The documentation provides a general overview of Azure Change Tracking and Inventory, mentioning support for both Windows and Linux. However, there is notable Windows bias: registry key tracking is described in detail with a large table of Windows-specific keys, while Linux equivalents (such as configuration file or daemon monitoring) are not discussed. Examples and screenshots focus on Windows concepts first, and there are no Linux-specific examples or tables for tracking Linux-specific changes (e.g., /etc files, systemd units).
Recommendations
  • Add equivalent Linux-focused sections, such as tracking changes to important configuration files (e.g., /etc/passwd, /etc/ssh/sshd_config) or monitoring Linux service/daemon changes.
  • Provide Linux-specific examples and tables similar to the Windows registry key table, listing common Linux files or directories that can be tracked.
  • Include screenshots or walkthroughs showing the experience on Linux systems.
  • Clarify parity between Windows and Linux features, noting any limitations or differences.
GitHub Create Pull Request
Azure Functions Guide for running C# Azure Functions in an isolated worker process ...icles/azure-functions/dotnet-isolated-process-guide.md
Medium Priority View Details →
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
⚠️ windows_first ⚠️ windows_tools ⚠️ powershell_heavy ⚠️ missing_linux_example
Summary
The documentation provides a comprehensive guide for running C# Azure Functions in an isolated worker process, but there are several instances of Windows bias. Windows-specific tools (Visual Studio, PowerShell) are often mentioned before Linux equivalents, and some example commands and instructions default to Windows-first presentation. While Linux is supported and referenced, examples and guidance for Linux users are less prominent, sometimes missing, or appear after Windows instructions. Azure PowerShell is listed as a resource creation method, but Bash/Azure CLI is not always equally emphasized. Some deployment and configuration instructions show Windows commands first, and ReadyToRun publishing examples default to Windows. The documentation does mention Linux support and provides Linux-specific instructions in some sections, but overall, Windows approaches are more visible and prioritized.
Recommendations
  • Ensure that every section presenting Windows-specific tools or commands also provides Linux/macOS equivalents, ideally side-by-side or with equal prominence.
  • When listing options for resource creation, deployment, or configuration, present Azure CLI and Bash examples before or alongside Windows/PowerShell examples.
  • Add explicit Linux/macOS examples for common developer workflows (e.g., using VS Code, Azure CLI, Bash scripts) where only Windows or PowerShell is shown.
  • In tables and lists, alternate the order of Windows and Linux options to avoid implicit prioritization.
  • Clarify when instructions are cross-platform and highlight any differences for Linux/macOS users.
  • For ReadyToRun and runtime identifier tables, ensure Linux examples are as detailed as Windows, and provide explicit Linux publishing commands.
GitHub Create Pull Request
Azure Functions Migrate C# app from in-process to isolated worker model ...es/azure-functions/migrate-dotnet-to-isolated-model.md
Medium Priority View Details →
Reviewed by: LLM Analysis
Issues: 2 bias types
Detected Bias Types
⚠️ powershell_heavy ⚠️ missing_linux_example
Summary
The documentation provides only Azure PowerShell scripts for identifying function apps to migrate, with no equivalent Azure CLI (cross-platform) or Bash examples. All other migration steps are platform-agnostic, but the initial discovery step assumes PowerShell, which is less common on Linux/macOS.
Recommendations
  • Add Azure CLI (az) command examples for identifying in-process function apps, alongside the PowerShell script.
  • Explicitly mention that the PowerShell script can be run on any platform with PowerShell Core installed, or provide Bash alternatives.
  • Wherever possible, present cross-platform tools (e.g., Azure CLI) before or alongside Windows-specific tools.
GitHub Create Pull Request
Azure Functions Migrate Consumption plan apps to Flex Consumption in Azure Functions ...unctions/migration/migrate-plan-consumption-to-flex.md
Medium Priority View Details →
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
⚠️ windows_first ⚠️ powershell_heavy ⚠️ missing_linux_example ⚠️ windows_tools
Summary
The documentation provides migration guidance for both Windows and Linux Azure Functions apps, but there is a notable Windows-first bias in several sections. Windows/PowerShell/Azure CLI examples and instructions are often presented before their Linux equivalents, and some migration steps (especially for Windows) are more detailed or have more automation support. The Linux migration process is covered, but the automated CLI migration tool is only available for Linux, while Windows users must follow more manual, step-by-step instructions. Some sections (such as Infrastructure as Code) show parity, but overall, Windows tools and patterns are mentioned first or more prominently.
Recommendations
  • Ensure Linux and Windows instructions/examples are presented with equal prominence and order, possibly by alternating which platform appears first in each section.
  • Where automation is available only for Linux (e.g., az functionapp flex-migration), clearly state this and provide equivalent scripts or guidance for Windows users where possible.
  • Add more Linux-specific troubleshooting steps and examples, especially for areas where Windows users have more detailed guidance.
  • Review all CLI and portal instructions to ensure Linux-specific nuances (such as file system differences, shell commands, etc.) are addressed.
  • Consider adding a summary table at the top of each major section showing parity and differences between Windows and Linux migration steps.
GitHub Create Pull Request
Azure Functions Storage considerations for Azure Functions ...ain/articles/azure-functions/storage-considerations.md
Medium Priority View Details →
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
⚠️ windows_first ⚠️ powershell_heavy ⚠️ missing_linux_example
Summary
The documentation generally covers Azure Functions storage considerations in a cross-platform manner, but several sections show subtle Windows bias. Windows plans and behaviors are often mentioned first, and PowerShell examples are provided for mounting file shares, while Linux-specific CLI examples are present but less detailed. Some features (like managed dependencies in PowerShell) are highlighted without Linux equivalents, and certain configuration settings are described with a Windows-first perspective. There are few explicit Linux examples, and Linux-specific guidance is often brief or relegated to later sections.
Recommendations
  • Ensure that Linux and macOS examples are presented alongside Windows/PowerShell examples, especially for tasks like mounting file shares and configuring storage settings.
  • Where features differ between Windows and Linux (e.g., managed dependencies), clarify Linux alternatives or explicitly state limitations.
  • Present cross-platform CLI instructions (Azure CLI, Bash, etc.) before or alongside PowerShell commands, and provide parity in example depth and detail.
  • Highlight Linux-specific behaviors and options earlier in relevant sections, not only in dedicated Linux subsections.
  • Add more Linux/macOS troubleshooting and best practice notes where applicable.
GitHub Create Pull Request
Azure Netapp Files Create an SMB volume for Azure NetApp Files ...-netapp-files/azure-netapp-files-create-volumes-smb.md
Medium Priority View Details →
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
⚠️ windows_tools ⚠️ powershell_heavy ⚠️ missing_linux_example ⚠️ windows_first
Summary
The documentation is focused on creating and managing SMB volumes in Azure NetApp Files, which is a protocol supported by both Windows and Linux. However, the instructions and examples for managing access and permissions are exclusively Windows-centric, referencing Windows tools (MMC, Windows SMB client, Windows File Browser) and omitting Linux methods for mounting and managing SMB shares. Windows terminology and screenshots are used throughout, and Linux alternatives are not mentioned or provided.
Recommendations
  • Add examples and instructions for mounting SMB volumes from Linux clients (e.g., using the mount.cifs command).
  • Include guidance on managing SMB share and NTFS permissions from Linux, such as using smbclient, setfacl, or other relevant tools.
  • Provide parity in screenshots and step-by-step instructions for Linux environments where applicable.
  • Clarify which steps are Windows-only and which are cross-platform, and link to Linux-specific documentation where relevant.
GitHub Create Pull Request
Azure Netapp Files SMB performance best practices for Azure NetApp Files ...ure-netapp-files/azure-netapp-files-smb-performance.md
Medium Priority View Details →
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
⚠️ windows_first ⚠️ powershell_heavy ⚠️ windows_tools ⚠️ missing_linux_example
Summary
The documentation is heavily Windows-centric, with all examples, commands, and monitoring instructions using Windows tools (PowerShell cmdlets, Performance Monitor, etc.). There are no Linux/macOS SMB client examples, nor any mention of how to monitor or tune SMB performance from non-Windows clients. Windows terminology and tools are presented exclusively and first throughout, creating friction for Linux/macOS users wishing to optimize SMB performance with Azure NetApp Files.
Recommendations
  • Add equivalent SMB performance tuning and monitoring instructions for Linux/macOS clients (e.g., using smbclient, mount.cifs, or FIO on Linux).
  • Provide Linux/macOS command examples for checking SMB Multichannel, encryption, and signing status.
  • Include guidance on relevant Linux kernel options (e.g., cifs.ko module parameters) for SMB performance.
  • Mention Linux tools for network and SMB performance monitoring (e.g., iostat, nload, atop, Wireshark, etc.).
  • Clarify which recommendations are Windows-only and which are applicable to all SMB clients.
GitHub Create Pull Request
Azure Netapp Files Create volume replication for Azure NetApp Files ...etapp-files/cross-region-replication-create-peering.md
Medium Priority View Details →
Reviewed by: LLM Analysis
Issues: 2 bias types
Detected Bias Types
⚠️ powershell_heavy ⚠️ windows_first
Summary
The documentation page provides Azure PowerShell examples first and in detail for feature registration, with only a brief mention of Azure CLI as an alternative. This prioritizes Windows/PowerShell usage, which may create friction for Linux/macOS users who typically use Azure CLI. The rest of the guide relies on Azure Portal UI steps, which are cross-platform, but the initial registration step is notably PowerShell-centric.
Recommendations
  • Provide full Azure CLI command examples for feature registration and status checking, not just links.
  • Present CLI and PowerShell examples side-by-side or in parallel sections, rather than PowerShell first.
  • Clarify that both PowerShell and CLI are supported and equally valid for all steps.
  • Where possible, include bash script snippets or Linux/macOS-specific notes for command-line steps.
GitHub Create Pull Request
Azure Netapp Files Troubleshoot volume errors for Azure NetApp Files ...in/articles/azure-netapp-files/troubleshoot-volumes.md
Medium Priority View Details →
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
⚠️ windows_tools ⚠️ windows_first ⚠️ powershell_heavy
Summary
The documentation provides a mix of troubleshooting steps for SMB, dual-protocol, and NFS volumes. However, there is a notable Windows bias: Active Directory (AD) and Microsoft Entra Domain Services (formerly Azure AD DS) are referenced throughout, and several steps require the use of Windows tools (e.g., 'Active Directory Users and Computers', PowerShell commands like Set-ADComputer). In the NFSv4.1 Kerberos section, PowerShell is suggested for setting Kerberos encryption types, and Windows UI tools are referenced before any Linux alternatives. Windows-centric terminology and tools are often mentioned first or exclusively, even when Linux clients are involved.
Recommendations
  • For every PowerShell or Windows UI example (e.g., Set-ADComputer, Active Directory Users and Computers), provide equivalent Linux/Unix-based commands or workflows where possible (e.g., using ldapmodify, samba-tool, or other standard LDAP utilities).
  • When referencing AD user/group membership or permissions, clarify how these can be managed from Linux (e.g., via ldapmodify or other cross-platform tools), or explicitly state if a Windows environment is required.
  • In sections where troubleshooting involves NFS clients, ensure Linux-centric troubleshooting steps are given equal prominence and detail.
  • When referencing tools like 'nslookup', clarify that these are available on both Windows and Linux, and provide example commands for both platforms.
  • Where possible, avoid referencing Windows tools first if the issue is cross-platform, or alternate the order of examples.
GitHub Create Pull Request
Azure Relay Authenticate from an application - Azure Relay .../main/articles/azure-relay/authenticate-application.md
Medium Priority View Details →
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
⚠️ windows_first ⚠️ powershell_heavy ⚠️ missing_linux_example
Summary
The documentation page primarily demonstrates authentication with Azure Relay using .NET console applications, which are typically associated with Windows environments. The sample code and walkthrough focus on .NET and C#, with no explicit mention of how to run equivalent samples on Linux or macOS. In the 'Next steps' section, Azure PowerShell is listed before Azure CLI, and there is no guidance on Linux/macOS-specific setup or troubleshooting. Although Java and JavaScript samples are linked, the main walkthrough and code highlights are Windows/.NET-centric.
Recommendations
  • Add explicit instructions or notes on running the .NET sample on Linux and macOS (e.g., using .NET Core/.NET 6+).
  • Provide highlighted code samples or walkthroughs for Java and JavaScript, not just .NET.
  • Mention cross-platform compatibility of the Azure Relay SDKs and clarify any OS-specific requirements.
  • List Azure CLI before PowerShell in 'Next steps', or present both equally, to better support Linux/macOS users.
  • Include troubleshooting tips for common Linux/macOS issues (e.g., environment variables, certificate handling).
GitHub Create Pull Request
Azure Relay https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-relay/includes/relay-hybrid-connections-dotnet-get-started-client.md ...https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-relay/includes/relay-hybrid-connections-dotnet-get-started-client.md
Medium Priority View Details →
Reviewed by: LLM Analysis
Issues: 2 bias types
Detected Bias Types
⚠️ windows_first ⚠️ missing_linux_example
Summary
The documentation is written with a clear Windows bias: it instructs users to create a Console App (.NET Framework) project in Visual Studio, a Windows-only IDE and framework. There are no instructions or examples for Linux/macOS users (e.g., using .NET Core/.NET 5+ or cross-platform editors like VS Code). The NuGet package installation steps are also Visual Studio-centric, omitting CLI alternatives.
Recommendations
  • Provide instructions for creating a cross-platform .NET (Core/5+) console application using the 'dotnet new console' CLI command.
  • Include NuGet package installation steps using the 'dotnet add package' CLI, which works on all platforms.
  • Mention and show examples for using VS Code or other cross-platform editors.
  • Clarify whether the sample code is compatible with .NET Core/.NET 5+ and, if not, provide a cross-platform version.
GitHub Create Pull Request
Azure Relay https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-relay/includes/relay-hybrid-connections-http-requests-dotnet-get-started-client.md ...id-connections-http-requests-dotnet-get-started-client.md
Medium Priority View Details →
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
⚠️ windows_tools ⚠️ missing_linux_example ⚠️ windows_first
Summary
The documentation assumes the use of Visual Studio and .NET Framework, both of which are primarily Windows tools. It provides only Windows-centric instructions for project creation and NuGet package management, with no mention of cross-platform alternatives (e.g., .NET Core/SDK CLI, Visual Studio Code, or Linux/macOS development environments). There are no Linux/macOS-specific instructions or examples.
Recommendations
  • Add instructions for creating the project using the .NET CLI (e.g., 'dotnet new console') to support Linux/macOS users.
  • Mention that the Microsoft.Azure.Relay NuGet package can be installed via the CLI (e.g., 'dotnet add package Microsoft.Azure.Relay').
  • Clarify if the code sample works with .NET Core/.NET 5+ (which are cross-platform), and update the instructions to use a cross-platform .NET version if possible.
  • Include a note or section for Linux/macOS users describing how to set up their environment and run the sample.
  • If .NET Framework is required and the feature is Windows-only, explicitly state this to avoid confusion.
GitHub Create Pull Request
Azure Relay Authenticate with managed identities for Azure Relay resources .../articles/azure-relay/authenticate-managed-identity.md
Medium Priority View Details →
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
⚠️ windows_first ⚠️ missing_linux_example ⚠️ windows_tools
Summary
The documentation provides step-by-step instructions and examples exclusively for Windows VMs, including references to RDP and Windows-specific VM images. There are no equivalent instructions or examples for Linux VMs or non-Windows environments, despite Azure Relay and managed identities being cross-platform features. Linux and macOS users are left without guidance for enabling managed identity, deploying, or running the sample applications.
Recommendations
  • Add parallel instructions for enabling managed identity on Linux VMs, linking to the appropriate Azure documentation.
  • Provide examples for deploying and running the sample applications on Linux VMs, including how to connect (e.g., using SSH instead of RDP).
  • Clarify in the 'Sample app on VM accessing Relay entities' section that the steps are for Windows VMs, and provide a separate section for Linux VMs.
  • Ensure that sample code and instructions reference .NET Core/.NET 5+ (which are cross-platform) and show how to build and run the sample on Linux/macOS.
  • Mention or link to the Java and JavaScript samples in the context of Linux/macOS usage, not just in the final 'Samples' section.
GitHub Create Pull Request
Azure Relay https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-relay/includes/relay-hybrid-connections-http-requests-dotnet-get-started-server.md ...id-connections-http-requests-dotnet-get-started-server.md
Medium Priority View Details →
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
⚠️ windows_tools ⚠️ missing_linux_example ⚠️ windows_first
Summary
The documentation assumes the use of Visual Studio and .NET Framework, both of which are primarily Windows tools. There are no instructions or examples for creating the project using cross-platform tools (e.g., .NET Core/SDK CLI, VS Code), nor any mention of Linux/macOS compatibility. All setup steps are tailored to Windows users.
Recommendations
  • Add instructions for creating the project using the .NET CLI (e.g., 'dotnet new console') which works on Linux/macOS.
  • Clarify whether Microsoft.Azure.Relay supports .NET Core/.NET 5+ and, if so, provide cross-platform code/project instructions.
  • Mention and provide examples for using editors like VS Code or JetBrains Rider, which are available on Linux/macOS.
  • If the feature is not Windows-only, explicitly state Linux/macOS compatibility and provide parity in setup steps.
GitHub Create Pull Request
Azure App Configuration Configuration Provider Overview ...e-app-configuration/configuration-provider-overview.md
Low Priority View Details →
Reviewed by: LLM Analysis
Issues: 1 bias type
Detected Bias Types
⚠️ windows_first
Summary
The documentation lists .NET-based libraries (Microsoft.Extensions.Configuration.AzureAppConfiguration, ASP.NET Core, Azure Functions, .NET Framework) first in the configuration provider libraries table, before Java, Python, JavaScript, and Go equivalents. However, all platforms and languages are covered, and there are no Windows-specific tools, examples, or patterns. No PowerShell or Windows-only instructions are present.
Recommendations
  • Consider alphabetizing or grouping the configuration provider libraries table by language/platform rather than listing .NET/Windows-centric options first.
  • Explicitly note cross-platform compatibility for .NET Standard/Core libraries, clarifying that they work on Linux/macOS as well as Windows.
  • Ensure that sample links for .NET libraries include Linux/macOS usage where applicable.
GitHub Create Pull Request
Azure Netapp Files Azure NetApp Files for Azure Government ...b/main/articles/azure-netapp-files/azure-government.md
Low Priority View Details →
Reviewed by: LLM Analysis
Issues: 2 bias types
Detected Bias Types
⚠️ windows_first ⚠️ powershell_heavy
Summary
The documentation provides access instructions for Azure NetApp Files in Azure Government using the Azure portal, Azure CLI, REST API, and PowerShell. While the CLI and REST API sections are cross-platform, the PowerShell section is detailed and prominent, and PowerShell is a Windows-centric tool. The PowerShell access section is more extensive than the CLI section, and PowerShell is mentioned in the 'Next steps' links before any Linux-native automation options. There are no Linux/macOS-specific examples or mentions of Bash, shell scripting, or automation tools commonly used on those platforms.
Recommendations
  • Add Bash or shell script examples for connecting to Azure Government using Azure CLI, demonstrating automation workflows on Linux/macOS.
  • Include a note clarifying that Azure CLI is fully supported on Linux/macOS and provide links to installation instructions for those platforms.
  • Balance the PowerShell section with equivalent detail for CLI usage, including example scripts for common NetApp Files tasks.
  • Mention cross-platform automation options (e.g., Python SDK, Terraform) if relevant for Azure NetApp Files.
GitHub Create Pull Request
API Center Include file ...ter/includes/configure-managed-identity-apim-reader.md
Low Priority View Details →
Reviewed by: LLM Analysis
Issues: 2 bias types
Detected Bias Types
⚠️ windows_first ⚠️ powershell_heavy
Summary
The documentation provides both Bash and PowerShell examples for Azure CLI commands, but PowerShell examples are shown immediately after Bash for every step, rather than grouping them or indicating platform parity. The PowerShell examples are labeled as 'Formatted for PowerShell', but there is no explicit mention of Linux/macOS users or guidance for Bash on those platforms. The ordering and labeling may subtly prioritize Windows/PowerShell users.
Recommendations
  • Clearly label Bash examples as suitable for Linux/macOS and PowerShell for Windows.
  • Consider grouping examples by platform (e.g., 'Linux/macOS (Bash)' and 'Windows (PowerShell)') rather than alternating for each command.
  • Add a short note clarifying that Bash examples are for Linux/macOS and PowerShell for Windows, ensuring both user groups know which to use.
  • If possible, provide a tabbed interface or clearer separation to reduce confusion.
GitHub Create Pull Request
API Center Quickstart - Create Your Azure API Center - Bicep ...ob/main/articles/api-center/set-up-api-center-bicep.md
Low Priority View Details →
Reviewed by: LLM Analysis
Issues: 2 bias types
Detected Bias Types
⚠️ windows_first ⚠️ powershell_heavy
Summary
The documentation provides both Azure CLI and Azure PowerShell examples for deploying the Bicep file, but PowerShell is featured equally and referenced in metadata and prerequisites. The page does not mention Linux/macOS-specific considerations, nor does it provide shell-specific guidance for those platforms. The order of presentation sometimes places PowerShell before or alongside CLI, which may subtly favor Windows users.
Recommendations
  • Explicitly state that Azure CLI works cross-platform (Windows, Linux, macOS) and is recommended for non-Windows users.
  • Add notes or links for Linux/macOS users about prerequisites for Bicep and Azure CLI (e.g., installation instructions, file path conventions).
  • Ensure CLI examples are shown first, as CLI is platform-agnostic.
  • Clarify that PowerShell examples are primarily for Windows users, and suggest Bash or shell alternatives for Linux/macOS where relevant.
GitHub Create Pull Request
API Management Deploy an Azure API Management Instance to Multiple Azure Regions ...management/api-management-howto-deploy-multi-region.md
Low Priority View Details →
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
⚠️ windows_tools ⚠️ powershell_heavy ⚠️ windows_first
Summary
The documentation page provides command-line examples for managing multi-region Azure API Management instances, but only includes Azure PowerShell and Azure CLI examples. The PowerShell cmdlet (set-azapimanagement) is mentioned alongside the CLI, and Windows-centric terminology (context menu, UI navigation) is used. There are no Linux/macOS-specific instructions or examples, and Windows tools are referenced before their cross-platform equivalents.
Recommendations
  • Add explicit Linux/macOS parity notes for Azure CLI usage, clarifying that all CLI commands work cross-platform.
  • Include bash shell examples for CLI commands, and clarify any OS-specific differences (such as line continuations, quoting).
  • When referencing PowerShell, note that Azure PowerShell is available on Linux/macOS, or provide equivalent CLI commands where possible.
  • Avoid Windows-centric UI terminology (e.g., 'context menu', '... button') or clarify how these actions are performed on other platforms.
  • Consider adding screenshots or instructions for Azure Portal navigation on non-Windows platforms if UI differs.
GitHub Create Pull Request
API Center Include file .../includes/configure-managed-identity-kv-secret-user.md
Low Priority View Details →
Reviewed by: LLM Analysis
Issues: 2 bias types
Detected Bias Types
⚠️ powershell_heavy ⚠️ windows_first
Summary
The documentation provides both Bash and PowerShell examples for Azure CLI commands, but the PowerShell examples are shown immediately after the Bash ones, and some variable assignment syntax is specifically labeled 'Formatted for PowerShell.' This may suggest a slight preference for Windows/PowerShell users, though Linux users are not blocked from completing the task.
Recommendations
  • Clearly separate Bash and PowerShell examples using tabs or callouts, so users can easily find their platform-specific instructions.
  • Provide a brief note explaining which example is for which platform (Linux/macOS vs. Windows), and clarify that Bash syntax applies to Linux/macOS and PowerShell to Windows.
  • Ensure that the Bash examples are complete and correct for Linux/macOS users, and consider listing Bash examples first if the majority of Azure CLI users are on Linux/macOS.
GitHub Create Pull Request
App Service Migrate from gateway-based to regional virtual network integration .../app-service/migrate-gateway-based-vnet-integration.md
Low Priority View Details →
Reviewed by: LLM Analysis
Issues: 2 bias types
Detected Bias Types
⚠️ windows_first ⚠️ powershell_heavy
Summary
The documentation provides Azure CLI, Azure PowerShell, and Azure Portal instructions for all migration steps. While both CLI and PowerShell are covered, PowerShell examples are consistently present and shown after CLI, and the documentation metadata includes 'devx-track-azurepowershell', suggesting a slight preference for PowerShell. However, Azure CLI examples are present and fully functional for Linux/macOS users, and no steps are Windows-only. The ordering of examples (CLI before PowerShell) is appropriate, but the inclusion of PowerShell in every example may indicate a minor Windows bias.
Recommendations
  • Ensure Azure CLI examples are always present and complete (which is currently the case).
  • Consider explicitly stating that Azure CLI is cross-platform and preferred for Linux/macOS users.
  • If possible, add Bash or shell script snippets for common tasks to further improve Linux parity.
  • Clarify in introductory sections that all steps can be completed on Linux/macOS using Azure CLI.
  • Review metadata and tags to ensure CLI parity is emphasized alongside PowerShell.
GitHub Create Pull Request
App Service Azure App Service Plans ...ob/main/articles/app-service/overview-hosting-plans.md
Low Priority View Details →
Reviewed by: LLM Analysis
Issues: 1 bias type
Detected Bias Types
⚠️ windows_first
Summary
The documentation for Azure App Service Plans is generally cross-platform, referencing both Windows and Linux as supported operating systems. However, there is a minor bias in the 'Managed Instance on Azure App Service (preview)' section, which is Windows-only and described before clarifying its exclusivity. The rest of the document does not show significant bias; examples and features are presented in a platform-neutral manner, and there are no PowerShell-heavy or Windows-tools-centric instructions.
Recommendations
  • Explicitly clarify Windows-only features (such as Managed Instance) at the start of relevant sections to avoid confusion for Linux users.
  • Where platform-specific features are discussed, provide clear cross-references or alternatives for Linux users, or state that no equivalent exists.
  • Ensure that links to pricing and feature tables include both Windows and Linux tabs or sections, if available.
  • Continue to present platform options (Windows, Linux) together when listing capabilities or configuration steps.
GitHub Create Pull Request
Azure Functions App settings reference for Azure Functions ...ain/articles/azure-functions/functions-app-settings.md
Low Priority View Details →
Reviewed by: LLM Analysis
Issues: 2 bias types
Detected Bias Types
⚠️ windows_first ⚠️ windows_tools
Summary
The documentation is generally cross-platform and covers both Windows and Linux scenarios for Azure Functions app settings. However, there are minor instances of Windows bias: some examples use Windows-style paths (e.g., %HOME%\typescript), and in a few cases, Windows-specific settings (like WEBSITE_NODE_DEFAULT_VERSION) are described before their Linux equivalents or without explicit Linux parity notes. Additionally, recommendations for programmatic management of settings mention Azure PowerShell before Azure CLI, which may suggest a slight preference for Windows tooling.
Recommendations
  • Ensure all examples that use file paths provide both Windows and Linux formats, or use platform-agnostic syntax.
  • When describing settings that differ between Windows and Linux, present both variants together, or clarify OS applicability up front.
  • When recommending tools for managing app settings, mention Azure CLI and Azure PowerShell together, or list Azure CLI first to reflect its cross-platform nature.
  • Review all sample values and code snippets for implicit Windows bias (e.g., environment variable syntax, path separators) and provide Linux/macOS equivalents where relevant.
GitHub Create Pull Request
Azure Functions Deployment technologies in Azure Functions ...s/azure-functions/functions-deployment-technologies.md
Low Priority View Details →
Reviewed by: LLM Analysis
Issues: 1 bias type
Detected Bias Types
⚠️ windows_first
Summary
The documentation generally presents deployment tools and examples in a cross-platform manner, referencing both Windows and Linux scenarios where relevant. However, in several sections (notably the 'Zip deploy' and 'Remote build' sections), Windows-based deployment scenarios and tools (such as Visual Studio and Visual Studio Code) are mentioned first, and the explanations of remote build start with Windows before Linux. There are no PowerShell-only examples, and Linux-specific tools and patterns are included, but Windows is often presented first. All major deployment methods and limitations for both Windows and Linux are clearly documented, and Linux-specific requirements (like remote build settings) are explained.
Recommendations
  • Where possible, alternate the order in which Windows and Linux deployment scenarios are presented, or present them in parallel (e.g., side-by-side tabs).
  • In tool-based deployment instructions, clarify cross-platform compatibility (e.g., Azure CLI and Core Tools work on all platforms).
  • When describing remote build, consider starting with a general overview, then splitting into Windows and Linux specifics without always leading with Windows.
  • Ensure that all examples and tool references are explicitly cross-platform unless a tool is Windows-only.
GitHub Create Pull Request