Scan Details - Linux-first Docs for Azure

1178

Pages Scanned

50

Pages Flagged

1178

Changed Pages

4.2%

% Pages Flagged

Scan Information

Started At: 2025-09-06 00:00:44

Finished At: 2025-09-06 00:26:01

Status: completed

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

Current Phase: discovery

Problematic Pages

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation demonstrates a Windows bias by referencing IIS (a Windows-only web server) as the example application for testing, and by linking to IIS setup instructions. There are no examples or guidance for setting up or testing with a Linux-based web application or server. Additionally, no Linux-specific tools, commands, or patterns are mentioned, and the only application setup guidance is for Windows environments.

Recommendations:

Provide parallel instructions for setting up a test web application on Linux (e.g., using Apache, Nginx, or a simple Python/Node.js HTTP server).
Include Linux-based examples and links for setting up SSL certificates and configuring backend applications.
Reference both Windows and Linux application scenarios equally when discussing prerequisites and test environments.
Avoid assuming IIS as the default or only test application; offer cross-platform alternatives.
Where possible, use neutral language and examples that are applicable to both Windows and Linux environments.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias by presenting Windows/Powershell examples and terminology before Linux equivalents, focusing on Windows-specific tools (PowerShell), and omitting Linux-specific automation or command-line examples. While Azure CLI is cross-platform, the PowerShell section is presented as an equivalent, but there are no Linux shell (bash) or scripting examples. The documentation also refers to the Azure portal UI, which is platform-agnostic, but does not provide parity for Linux users in automation or scripting contexts.

Recommendations:

Provide Linux shell (bash) scripting examples alongside PowerShell for automation tasks.
When listing SKU availability commands, present Linux and Windows examples together or alternate their order to avoid always listing Windows first.
Clarify that Azure CLI commands are cross-platform and can be run on both Windows and Linux, and provide explicit bash examples where appropriate.
Include notes or sections for Linux users, especially for automation, to ensure parity with Windows/PowerShell instructions.
Consider including a table or matrix showing which features and commands apply to Windows, Linux, and containers for clarity.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation demonstrates a mild Windows bias. In sections where both Windows and Linux are relevant (such as SKU availability), Windows is mentioned first. Automation examples are provided for both Azure CLI (cross-platform) and Azure PowerShell (Windows-centric), but there is no mention of Bash scripting or Linux-native automation tools. The portal UI instructions and screenshots do not distinguish between Windows and Linux hosting environments, and there is no explicit Linux-specific guidance or parity in scripting approaches.

Recommendations:

Alternate the order of Windows and Linux instructions/examples to avoid always presenting Windows first.
Include Bash scripting examples for Linux users, especially in the automation section.
Clarify in portal instructions and screenshots whether steps differ for Linux-hosted apps, or provide Linux-specific UI guidance if applicable.
Explicitly mention that Azure CLI is cross-platform and suitable for Linux/macOS users, and consider linking to Linux-specific CLI installation guides.
If PowerShell is included, consider also providing equivalent Bash or shell script examples to ensure Linux parity.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows bias by focusing on Windows-specific deployment patterns, tools, and examples. It references Visual Studio and Windows file paths, and provides instructions for accessing .NET Framework versions using Windows-only tools (Kudu CMD/PowerShell) and directories. There are no Linux-specific examples, nor is there guidance for configuring ASP.NET apps in Linux App Service environments, despite Azure App Service supporting Linux. The documentation assumes Windows as the default platform for ASP.NET apps.

Recommendations:

Add equivalent instructions and examples for Linux-based App Service environments, including how to check .NET runtime versions and access environment variables.
Include Linux shell (bash) commands and file paths where appropriate, such as for listing installed .NET runtimes.
Mention Linux deployment tools and patterns (e.g., VS Code, CLI, FTP, Git) alongside Visual Studio.
Clarify which steps are Windows-specific and provide links or inline guidance for Linux users.
Ensure parity in troubleshooting and diagnostics instructions for both Windows and Linux environments.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ powershell_heavy

Summary:

The documentation is heavily focused on Windows environments, specifically Azure App Service on Windows with iisnode. All configuration and troubleshooting steps reference Windows-specific tools, paths, and patterns (e.g., node.exe, web.config, iisnode, Win32 error codes, Kudu CMD/PowerShell). There are no examples or guidance for Linux-based Azure App Service environments, nor are Linux equivalents or cross-platform instructions provided.

Recommendations:

Add a parallel section or separate documentation for Node.js on Azure App Service for Linux, covering best practices and troubleshooting.
Include Linux-specific configuration examples (e.g., using PM2, Nginx, or Apache as process managers/reverse proxies instead of iisnode/IIS).
Provide Linux shell (bash) commands and file path examples alongside Windows CMD/PowerShell instructions.
Reference Linux log file locations and troubleshooting tools (e.g., journalctl, systemd logs) where appropriate.
Clarify at the top of the document that the current content is Windows-specific, and provide a link to Linux guidance if available.
When discussing tools or settings (e.g., debugging, profiling), mention cross-platform alternatives and how to use them on Linux.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation demonstrates a Windows bias by providing PowerShell scripts as the only automation example for identifying impacted Traffic Manager endpoints, without offering Bash, Azure CLI, or cross-platform alternatives. References to 'open PowerShell' and running '.ps1' scripts are Windows-centric, and there is no mention of equivalent Linux/macOS workflows. Additionally, the PowerShell script is mentioned before any CLI or REST API options, and no Linux shell or cross-platform scripting options are provided for the same tasks.

Recommendations:

Provide equivalent Bash or Azure CLI scripts for all PowerShell examples, especially for identifying Traffic Manager endpoints.
Explicitly mention that PowerShell Core is cross-platform, or provide instructions for running scripts on Linux/macOS if PowerShell is required.
Where automation is referenced, offer both Windows (PowerShell) and Linux/macOS (Bash/CLI) examples side by side.
Avoid language such as 'Open PowerShell' without also mentioning terminal/shell on other platforms.
Ensure that CLI and REST API examples are given equal prominence and are not only referenced after PowerShell scripts.
Consider linking to or providing sample scripts in Bash or Python for common administrative tasks.

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 notably more detailed, featuring extensive PowerShell scripting and Windows-specific file paths and tools. Windows configuration steps are more elaborate, with explicit use of PowerShell and Windows environment variables, while Linux instructions are more concise and rely on shell scripts. The order of presentation sometimes places Windows details before Linux equivalents, and the Windows approach uses Windows-native tools (PowerShell, .cmd files) without always offering Linux alternatives for similar automation or scripting.

Recommendations:

Ensure that Linux and Windows instructions are equally detailed, especially for advanced scenarios such as server-level configuration.
Provide Linux shell script equivalents for all PowerShell automation shown in the Windows section, including robust examples for copying Tomcat, transforming XML, and managing marker files.
Where possible, present Linux and Windows instructions in parallel or side-by-side tabs to avoid the perception of Windows-first bias.
Highlight cross-platform tools and approaches (e.g., use of Azure CLI, bash scripting) before platform-specific tools like PowerShell.
Explicitly mention differences in file system layout and permissions between Linux and Windows, and offer guidance for both platforms in all advanced scenarios.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation focuses exclusively on discovering ASP.NET web apps hosted on IIS servers within VMware environments, which are Windows-centric technologies. There are no examples, instructions, or mentions of discovering .NET apps hosted on Linux servers (e.g., Kestrel, Apache, Nginx), nor are Linux tools or patterns referenced. All discovery capabilities and resources are described in the context of Windows/IIS, with no Linux parity.

Recommendations:

Include information on discovering .NET web apps hosted on Linux servers, such as those running on Kestrel, Apache, or Nginx.
Provide examples or documentation links for Linux-based discovery scenarios, if supported by Azure Migrate.
Explicitly state if Linux-hosted .NET app discovery is not supported, and provide guidance or alternatives for Linux users.
Ensure that future updates to the documentation mention both Windows and Linux environments where applicable, and provide parity in examples and tooling references.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias by referencing Windows file paths (e.g., D:\home\site\wwwroot) before Linux equivalents, describing deployment directories and behaviors primarily in Windows terms, and omitting explicit Linux/macOS command-line examples or file paths in several sections. The document also references Windows-style directory separators (\) and patterns (e.g., <project-root>\app_data\jobs\...), and does not provide parity for Linux-specific deployment nuances or troubleshooting.

Recommendations:

Present both Windows and Linux file paths and directory structures side by side throughout the documentation (e.g., D:\home\site\wwwroot and /home/site/wwwroot).
Include Linux/macOS-specific command-line examples and notes where relevant, especially for file operations and deployment steps.
Use platform-agnostic directory separators (e.g., <project-root>/app_data/jobs/...) or clarify both styles.
Add troubleshooting tips and behavioral notes specific to Linux-based App Service environments.
Ensure that all references to tools (such as Azure Storage Explorer) are accompanied by cross-platform alternatives or clarifications on their availability.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation page demonstrates a strong Windows bias. All migration tools and examples focus exclusively on migrating from Windows environments, specifically from IIS servers. Only Windows-based tools (App Service Migration Assistant, PowerShell scripts) are mentioned, and there are no references to Linux-based web servers (such as Apache or Nginx) or Linux migration scenarios. PowerShell is the only scripting environment referenced, and all download links are for Windows executables or scripts. There are no Linux command-line or tool examples, nor any mention of Linux-specific migration considerations.

Recommendations:

Include guidance and examples for migrating .NET apps hosted on Linux web servers (e.g., Apache, Nginx, Kestrel) to Azure App Service.
Provide parity in tooling by referencing or developing migration tools that support Linux environments, and include download links for Linux-compatible versions.
Add Linux shell (bash) script examples alongside PowerShell, and document equivalent Linux commands for discovery and migration.
Mention Linux migration scenarios and considerations explicitly, including any limitations or differences compared to Windows migrations.
Clarify in the documentation if certain tools are Windows-only, and suggest alternative approaches for Linux users.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ powershell_heavy

Summary:

The documentation demonstrates a Windows bias in several ways: Windows-specific deployment methods (Web Deploy) are highlighted, and examples for these methods are only provided for Windows agents. Troubleshooting and FAQ sections focus on Windows agent requirements for certain features, with no Linux alternatives or parity. In some cases, Windows tools and patterns (such as IIS, Web Deploy, and web.config) are mentioned without Linux equivalents or guidance. Linux is mentioned as an option for agent selection, but detailed examples and troubleshooting for Linux scenarios are lacking.

Recommendations:

Provide equivalent Linux examples for all deployment scenarios, especially for advanced deployment methods (e.g., Web Deploy alternatives for Linux, or clarify limitations).
When mentioning Windows-specific tools (e.g., Web Deploy, IIS, web.config), also mention Linux equivalents (e.g., Kudu, Nginx/Apache, app-specific config files) or note if none exist.
In troubleshooting and FAQ sections, include Linux agent-specific guidance and error messages, not just Windows.
Avoid assuming Windows as the default; when presenting agent selection, alternate the order or provide parallel instructions for both Windows and Linux.
Where features are Windows-only, clearly state this and suggest best practices or workarounds for Linux users.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation shows subtle Windows bias by referencing Windows-specific tools (such as web.config and iisnode) without equivalent Linux guidance, and by omitting Linux-specific configuration examples or alternatives. While there is a brief mention of running on Linux and using PM2, most configuration and troubleshooting advice defaults to Windows-centric approaches, and Linux parity is not consistently addressed.

Recommendations:

For features like auto-healing, provide Linux-native configuration guidance (e.g., how to configure auto-healing or equivalent on Linux-based App Service plans, since web.config is not used).
When referencing iisnode or web.config, explicitly note their applicability (Windows only) and provide Linux alternatives (such as using process.json for PM2 or environment variables).
Add Linux-specific troubleshooting and configuration examples wherever Windows-specific tools or patterns are mentioned.
Ensure that all best practices and diagnostic steps are clearly documented for both Windows and Linux App Service environments, including any differences in supported features or configuration files.
Where possible, present Linux and Windows approaches side by side, or clarify which instructions apply to which platform.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a moderate Windows bias. Windows instructions, tools, and troubleshooting steps are often presented first or exclusively, with more detailed guidance and screenshots for Windows users. PowerShell is referenced for network testing, while Linux equivalents are not provided. The GUI for Hybrid Connection Manager is only available on Windows, and this is noted, but the overall tone and depth of guidance favor Windows environments. Some troubleshooting and verification steps are Windows-specific, and Linux users are sometimes directed to less detailed or alternative methods.

Recommendations:

Provide Linux-first or side-by-side instructions and examples, especially for common tasks like installation, troubleshooting, and network testing.
Include Linux equivalents for PowerShell commands (e.g., use 'nc', 'telnet', or 'curl' for connectivity tests).
Offer more detailed Linux CLI usage examples and screenshots, matching the depth of Windows GUI coverage.
Highlight any feature parity or limitations for Linux early and clearly, and suggest workarounds where possible.
Ensure that troubleshooting sections include both Windows and Linux commands and tools.
Where a GUI is not available on Linux, provide detailed CLI workflows and consider linking to community or third-party tools if appropriate.

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 are several subtle signs of Windows bias. Windows examples and tools (such as Kudu, Advanced Tools, and FTPS) are sometimes mentioned first or exclusively, and certain troubleshooting and deployment workflows are described in more detail for Windows. Some sections, like Java Flight Recorder usage, provide more step-by-step guidance for Windows (e.g., using Kudu Process Explorer) than for Linux. There are also references to Windows-specific conventions (e.g., web.config, C:\ paths) and tools without always providing Linux equivalents or context. In a few places, Linux-specific instructions are less detailed or are omitted.

Recommendations:

Ensure that all examples and instructions are provided for both Linux and Windows, with equal detail and order of presentation.
Where Windows tools (like Kudu/Advanced Tools, FTPS, web.config) are mentioned, provide Linux equivalents or clarify when they are not applicable.
Avoid using Windows-first ordering in tabbed sections or lists; alternate or start with Linux where appropriate.
Expand Linux troubleshooting and diagnostic sections to match the depth of Windows guidance (e.g., provide more details on finding PIDs, using SSH, or downloading files from Linux containers).
Review for any missing Linux-specific examples, especially for deployment, logging, and advanced configuration scenarios.
Where possible, use cross-platform tools and neutral terminology (e.g., use Azure CLI or REST API examples instead of PowerShell or Windows-only tools).

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a mild Windows bias. It references Azure Storage Explorer with a link that defaults to Windows instructions and does not mention Linux or cross-platform alternatives. There are no explicit Linux-specific instructions or examples, and the only tool-specific guidance (Storage Explorer) is presented as if Windows is the default environment. No PowerShell commands are present, but the absence of Linux CLI or tool alternatives and the 'windows' tab in the Storage Explorer link indicate a subtle preference for Windows.

Recommendations:

Explicitly mention that Azure Storage Explorer is cross-platform and provide links or instructions for Linux and macOS users.
Wherever a tool is referenced (such as Storage Explorer), include notes or links for installation and usage on Linux.
If there are command-line alternatives (e.g., using az CLI or other open-source tools) for uploading files or generating SAS tokens, provide those examples alongside GUI-based instructions.
Avoid defaulting documentation links to Windows-specific tabs or sections; use neutral or cross-platform links.
Add a brief section or note confirming that all Azure CLI commands shown work identically on Linux, macOS, and Windows.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a moderate Windows bias, especially in the .NET/ASP.NET sections, 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 there is inconsistent parity in Linux/CLI examples across stacks. The 'Next step' call-to-action specifically promotes an ASP.NET (typically Windows-centric) workflow, reinforcing the bias.

Recommendations:

Ensure that for every Windows or PowerShell example, a Linux/CLI/Azure CLI example is provided and given equal prominence.
Reorder tool lists to alternate or start with cross-platform or Linux-native tools (e.g., Visual Studio Code, CLI) before Windows-only tools.
Avoid defaulting quickstart links to Windows or PowerShell tabs; use neutral or user-detecting defaults.
Add explicit Linux/CLI instructions or pivots where missing, especially for .NET workflows.
Balance 'Next step' call-to-actions to include at least one Linux-native or cross-platform example (e.g., deploying with Azure CLI or from Linux).

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows bias by primarily referencing Windows development tools and workflows (e.g., Visual Studio, right-click actions, NuGet Package Manager), and omitting explicit Linux or cross-platform alternatives. Instructions for package installation and project setup are centered on Visual Studio and GUI actions, with only passing mention of CLI alternatives. There are no Linux-specific examples or guidance for common Linux development environments.

Recommendations:

Provide explicit Linux and cross-platform instructions for all steps, including project creation, file editing, and package installation (e.g., using dotnet CLI, VS Code, or JetBrains Rider).
Include CLI-based examples for adding files and editing navigation, rather than only GUI/Visual Studio instructions.
List CLI/NuGet CLI instructions before or alongside Visual Studio/NuGet Package Manager steps.
Mention and demonstrate how to set environment variables and manage secrets on Linux (e.g., using Azure CLI, environment files, or Key Vault references via CLI).
Clarify that the instructions are cross-platform, and highlight any OS-specific considerations for Linux users.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation demonstrates a moderate Windows bias. While it covers both Azure CLI and Azure PowerShell for command-line operations, PowerShell examples are consistently provided alongside CLI, and sometimes with more detailed explanations. Windows-specific tools and configuration patterns (such as Web.config and IIS applicationInitialization) are referenced without Linux equivalents. There is also a lack of explicit Linux-native configuration examples (e.g., for warm-up or rewrite rules), and troubleshooting sections reference Windows file paths and concepts. The documentation does mention 'web app on Linux' in the introduction, but practical parity in examples and troubleshooting is lacking.

Recommendations:

Provide Linux-native configuration examples, such as using appsettings.json, .env files, or startup scripts for warm-up and initialization, especially where Web.config or IIS is referenced.
When discussing troubleshooting, include Linux file paths and logging locations (e.g., /home/LogFiles) in addition to Windows paths.
Clarify which features (such as auto swap) are not supported on Linux, and suggest Linux-appropriate alternatives or workarounds.
For rewrite rules and warm-up, provide Nginx/Apache or Kestrel equivalents alongside IIS/Web.config examples.
Ensure that Azure CLI examples are presented at least as prominently as PowerShell, and consider leading with CLI (which is cross-platform) rather than PowerShell (which is traditionally Windows-centric).
Explicitly mention any differences in slot behavior or configuration between Windows and Linux App Service plans.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows bias by referencing Windows-specific SKUs and features first (e.g., 'I1v2 Windows'), providing detailed subnet/IP calculations only for Windows Containers, and listing Windows-centric tools (Visual Studio remote debugging, Web Deploy) in port tables without mentioning Linux equivalents or providing Linux-specific examples. There are no Linux-specific configuration or troubleshooting examples, and Linux container/app scenarios are not illustrated in the same detail as Windows.

Recommendations:

Provide parallel examples and calculations for Linux containers and App Service plans, similar to the detailed Windows Container IP address calculation.
List Linux deployment and debugging tools (e.g., SSH, SFTP, VS Code Remote) alongside Windows tools in port tables and documentation.
Ensure that any references to SKUs or features (such as standby instance behavior) include both Windows and Linux variants, or clarify differences.
Add Linux-specific notes or examples where platform behavior differs, especially in networking, scaling, and deployment scenarios.
Review the order of presentation to avoid always listing Windows first; consider alternating or grouping by OS.
Include links to Linux-focused resources and troubleshooting guides where appropriate.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation lists Windows file types and tools (cmd, bat, exe, PowerShell) in detail and with multiple examples, while Linux support is described more briefly and generically. Windows examples are given first and are more comprehensive, whereas Linux examples are minimal and lack parity in detail.

Recommendations:

Provide a more detailed list of supported file types for Linux, similar to the Windows section (e.g., mention .py, .pl, .rb, .js, .jar, etc., where applicable).
Include explicit examples for Linux code and container tabs, matching the specificity of the Windows examples.
Avoid listing Windows tools (cmd, bat, exe, PowerShell) exclusively; if mentioning tools, provide Linux equivalents (e.g., bash, python, node, etc.).
Consider presenting Windows and Linux sections in parallel structure, ensuring both platforms receive equal detail and example coverage.
Where possible, avoid always listing Windows first, or clarify that the order does not imply priority.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a moderate Windows bias. In sections where users are instructed to retrieve outbound IP addresses, both Azure CLI and Azure PowerShell examples are provided, but PowerShell is always listed after CLI and is not explicitly labeled as 'Windows only' or 'for Windows users.' There are no explicit Linux shell or Bash script examples beyond the use of Azure CLI, and no mention of platform-specific nuances for Linux users. Additionally, outbound IPv6 support is noted as being in public preview only for Windows apps, but this is a product limitation rather than a documentation bias. However, the documentation does not provide guidance or alternative suggestions for Linux users regarding this limitation.

Recommendations:

Clearly label PowerShell examples as 'for Windows users' and Azure CLI examples as 'cross-platform' or 'for Linux/macOS/Windows'.
Provide explicit Bash or Linux shell command examples where appropriate, especially for common tasks like querying IP addresses.
Where a feature is Windows-only (such as outbound IPv6 support), offer alternative guidance or workarounds for Linux users, or explicitly state the limitation and expected roadmap.
Ensure that all instructions and examples are presented in a platform-neutral order, or alternate the order to avoid always listing Windows tools second.
Add a section or callout summarizing any platform-specific differences or limitations, so Linux users are aware of what does and does not apply to them.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ windows_first

Summary:

The documentation page demonstrates a Windows bias by providing only PowerShell examples for command-line operations, omitting equivalent instructions for Linux users (such as Azure CLI or Bash). The use of PowerShell cmdlets and Windows-centric tooling is emphasized, with no mention of cross-platform or Linux-native alternatives. This may hinder accessibility and usability for developers working on non-Windows platforms.

Recommendations:

Add Azure CLI examples alongside PowerShell for all command-line operations, as Azure CLI is cross-platform and widely used on Linux and macOS.
Explicitly mention that PowerShell examples are Windows-centric and provide Bash or shell script equivalents where possible.
Include a section or callout for Linux/macOS users, guiding them to use Azure CLI or REST API for per-app scaling.
Ensure that future documentation does not assume a Windows environment by default, and strive for parity in tooling and example coverage.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows-first bias in several areas. Windows-specific tools, paths, and behaviors are often mentioned before or instead of their Linux equivalents. Many examples and explanations use Windows conventions (such as D:\home, .bat files, and Windows process names like w3wp.exe) without always providing Linux alternatives. Some settings are described only in the context of Windows tools or workflows (e.g., MSDeploy, Web Deploy, IIS, applicationHost.config), and Linux-specific guidance is sometimes missing or less detailed.

Recommendations:

For every Windows-specific example (such as file paths like D:\home or %HOME%), provide the Linux equivalent (e.g., /home or $HOME) alongside.
When referencing Windows tools (e.g., MSDeploy, Web Deploy, IIS), also mention or link to Linux deployment methods and tools (such as Oryx, Kudu for Linux, or CLI-based deployments).
Avoid using Windows process names (like w3wp.exe) or configuration files (like applicationHost.config) without clarifying their Linux/container equivalents or stating that they are not applicable.
Ensure that all environment variable descriptions specify applicability to both Windows and Linux, or clearly state when a variable is platform-specific.
Add Linux/POSIX shell command examples where PowerShell or Windows batch examples are given.
Review and expand sections where Linux behaviors or settings are only briefly mentioned or omitted, ensuring Linux users have parity in guidance and troubleshooting steps.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page exhibits a Windows bias by referencing Windows-specific paths (e.g., D:\home), tools, and deployment conventions throughout, without providing equivalent Linux examples. Windows containers are mentioned before Linux containers, and instructions for checking folder sizes and environment variables rely on Windows-centric site extensions and Kudu, which are more familiar to Windows users. There are no explicit Linux shell or file path examples, nor guidance for Linux-based App Service environments.

Recommendations:

Add Linux-specific examples for file paths (e.g., /home/site/wwwroot) and environment variables.
Include instructions for checking folder sizes and cache status using Linux shell commands (e.g., du, ls) in addition to Windows tools.
Mention Linux containers and built-in Linux environments alongside Windows containers, and provide parity in explanations.
Clarify which instructions apply to Windows, Linux, or both, and provide guidance for Linux users where behavior or tooling differs.
Reference Linux-compatible site extensions or alternatives for disk usage and diagnostics.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation demonstrates a moderate Windows bias. It references Windows-centric tools and workflows (such as Visual Studio Code and PowerShell/dotnet commands), and omits explicit Linux/macOS equivalents or guidance. The ordering of examples and tool recommendations often assumes a Windows environment, and there is a lack of parity in shell/command-line instructions for Linux users.

Recommendations:

Provide explicit Linux/macOS command-line examples alongside Windows/PowerShell commands, especially for dotnet and environment variable setup.
When referencing Visual Studio Code, clarify that it is cross-platform and provide alternative instructions for users who may use other editors or command-line workflows.
Include bash/zsh shell examples for setting environment variables (e.g., export PLAYWRIGHT_SERVICE_URL=...), not just .env or PowerShell approaches.
For .NET/NUnit instructions, show both PowerShell and bash (or generic shell) command variants (e.g., dotnet test -- NUnit.NumberOfTestWorkers=20 works on both, but clarify if there are differences).
Avoid assuming the use of Windows-specific tools or UI patterns (such as 'Test Explorer' in VS Code) as the default; note cross-platform alternatives or limitations.
Explicitly state platform compatibility for all steps, and add notes or links for Linux/macOS users where workflows or commands differ.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

Summary:

The documentation provides extensive PowerShell examples and references, which are primarily relevant to Windows environments. PowerShell is featured as a first-class automation option alongside Azure CLI and ARM templates, but there is no mention of Bash, shell scripting, or Linux-native tooling. The CLI examples use 'az', which is cross-platform, but the PowerShell sections are detailed and sometimes offer functionality not available in CLI (e.g., user-assigned identity for Functions). There are no explicit Linux shell or Bash examples, and PowerShell is presented as a default scripting language for automation, which may not be familiar or preferred by Linux users.

Recommendations:

Add Bash or shell script examples for common tasks, especially where PowerShell is featured.
Clarify that Azure CLI commands work identically on Linux, macOS, and Windows, and provide explicit Linux terminal examples where possible.
Where PowerShell is used for automation, offer equivalent Bash or Python scripting examples to ensure Linux users have parity.
Avoid presenting PowerShell as the only or primary scripting automation language; balance with Linux-native options.
Explicitly mention cross-platform compatibility in sections discussing automation and scripting.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by referencing Windows-specific tools (IIS, Procdump, web.config), providing PowerShell as the only CLI example, and linking to Windows-focused resources. There is a lack of Linux-specific troubleshooting guidance, and Linux-native tools or patterns are not mentioned. The Kudu console is described in terms of PowerShell and DOS commands, with no mention of Bash or Linux shell support. Diagnostic and mitigation steps (such as auto-heal and profiler) are described with a Windows/.NET focus, and links point to Windows-centric articles.

Recommendations:

Provide Linux-specific examples and instructions alongside Windows ones, especially for enabling diagnostics, collecting logs, and using the Kudu console (e.g., mention Bash support and Linux command equivalents).
Reference Linux-native tools and patterns (such as using tail, grep, or journalctl for logs, and Linux process dump tools like gcore or dotnet-dump for .NET Core apps on Linux).
Clarify which features and tools are available or behave differently on Linux App Service plans (e.g., Application Insights Profiler, auto-heal, web.config triggers).
Include links to Linux-focused documentation and troubleshooting guides.
When mentioning PowerShell, also provide Azure CLI or Bash alternatives for cross-platform parity.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows-first bias: logging types and features are described for Windows in more detail and before Linux equivalents. Several logging features (web server logging, detailed error messages, failed request tracing) are documented only for Windows, with no Linux alternatives or explanations. Windows-specific tools and file paths (e.g., Log Parser, D:\home\LogFiles) are mentioned, while Linux equivalents are not provided. Linux logging is described more briefly, and some features are explicitly unavailable or not explained for Linux.

Recommendations:

Provide equivalent Linux examples and instructions for all logging types, or clearly state if a feature is unavailable on Linux.
Include Linux file paths and access methods alongside Windows paths (e.g., /home/LogFiles vs D:\home\LogFiles) in all relevant sections.
Mention Linux-compatible tools for log analysis (e.g., grep, less, jq) where Windows tools like Log Parser are referenced.
Clarify any feature gaps between Windows and Linux, and suggest workarounds or alternatives for Linux users.
Ensure that Linux and container scenarios are described with the same level of detail as Windows scenarios, including code/configuration examples where appropriate.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias by frequently referencing PowerShell, using Windows-centric tools and terminology (e.g., AzPowershell, PowerShell@2 tasks), and omitting explicit Linux shell or cross-platform CLI examples. Even when CI runners are set to Ubuntu, the scripts and instructions default to PowerShell syntax and tools, with no Bash or Linux-native alternatives provided. This may hinder Linux-first or cross-platform users.

Recommendations:

Provide equivalent Bash or sh examples alongside PowerShell commands, especially for npm, dotnet, and Playwright CLI usage.
When showing CI pipeline YAML, offer both PowerShell and Bash script variants, or use cross-platform steps where possible.
Avoid using Windows-specific terminology (e.g., 'AzPowershell', 'PowerShell@2') as the default; clarify when steps are cross-platform or provide Linux/macOS alternatives.
Explicitly mention that all steps work on Linux/macOS, and highlight any platform-specific considerations.
For command-line snippets, default to Bash or provide both Bash and PowerShell versions, especially for Playwright and npm commands.
Review all code blocks and workflow steps to ensure Linux users are not required to mentally translate from PowerShell to Bash.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation demonstrates a mild Windows bias. It references Azure PowerShell explicitly for restarting the Application Gateway, without providing equivalent Azure CLI (cross-platform) or Bash examples. The only command-line tooling mentioned is PowerShell, and there are no Linux/Unix-specific instructions or examples. This may make the documentation less approachable for Linux or cross-platform users.

Recommendations:

Wherever Azure PowerShell commands are referenced, provide equivalent Azure CLI (az) commands and examples.
When mentioning how to restart or manage Application Gateway resources, include both PowerShell and CLI/Bash command snippets side by side.
Ensure that all instructions and examples are platform-neutral or explicitly include both Windows and Linux usage patterns.
Add a note clarifying that both Azure PowerShell and Azure CLI are supported, and link to relevant cross-platform installation guides.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation demonstrates a moderate Windows bias. While Azure CLI is used for most automation steps (which is cross-platform), the tutorial and code samples focus exclusively on .NET (C#) and reference Windows-centric tools and workflows. SQL Server Management Studio (SSMS) and Active Directory Integrated authentication are mentioned without Linux alternatives. Local debugging guidance and publishing instructions prioritize Visual Studio and Git Bash, with no mention of Linux-native editors or deployment tools. There are no Linux-specific examples for connecting to SQL Database, nor are cross-platform alternatives to SSMS (like Azure Data Studio) suggested.

Recommendations:

Add Linux-specific instructions for local debugging, such as using Azure Data Studio or sqlcmd on Linux.
Include examples of connecting to Azure SQL Database from Linux environments, both for administration and app development.
Mention cross-platform editors (e.g., VS Code, JetBrains Rider) and deployment workflows for Linux/Mac users.
Provide alternative publishing instructions using Azure CLI or Git from Linux terminals.
Reference Azure Data Studio as a cross-platform alternative to SSMS for database management.
Clarify that Azure CLI and jq commands work on Linux, and provide troubleshooting tips for common Linux shell issues.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows-centric bias. Visual Studio for Windows is presented as the primary development environment, with detailed steps and UI navigation. PowerShell and Windows-specific tools (e.g., sqlcmd in PowerShell, Visual Studio) are used for critical steps like granting database permissions, with no equivalent Linux or cross-platform alternatives shown. Linux or macOS development environments are only briefly mentioned (Azure CLI tab), and there are no examples for connecting to SQL Database or running sqlcmd from Linux/macOS terminals. The documentation assumes a Windows workflow for key operations, leaving Linux users to infer or adapt steps.

Recommendations:

Provide explicit Linux/macOS examples for all command-line operations, especially for connecting to Azure SQL Database (e.g., using sqlcmd or Azure Data CLI from Bash).
Include instructions for using cross-platform editors (e.g., Visual Studio Code) for all steps, not just authentication.
When presenting multiple environments, avoid putting Windows/PowerShell first or giving them more detail—present all supported platforms equally.
Add a section or tab for Linux/macOS users in the 'Set up your development environment' and 'Grant permissions' steps, with commands and tools native to those platforms.
Mention and demonstrate the use of Azure Data CLI (azdata) or sqlcmd for Linux/macOS, and provide installation instructions if needed.
Ensure all screenshots and UI navigation steps are either cross-platform or have equivalents for non-Windows environments.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation provides both Azure CLI and Azure PowerShell examples for configuring active geo-replication, but it demonstrates a Windows bias by including PowerShell examples (which are traditionally Windows-centric) and not mentioning or providing Linux shell (bash) equivalents. The CLI examples are generic, but there is no explicit guidance or examples for Linux users (e.g., bash scripts, shell environment notes). PowerShell is presented equally alongside CLI, which may confuse or disadvantage Linux users who do not use PowerShell. There are no references to Linux-specific tools or workflows, and the document does not clarify cross-platform compatibility for the CLI or PowerShell commands.

Recommendations:

Explicitly state that Azure CLI commands work cross-platform (Windows, Linux, macOS) and can be run in bash or other shells.
Provide bash (Linux shell) script examples alongside PowerShell, or clarify that the CLI examples are intended for use in any shell.
If PowerShell is included, clarify that PowerShell Core is available on Linux and macOS, or provide links to installation instructions.
Add a note or section for Linux/macOS users, highlighting any differences or confirming parity.
Avoid presenting PowerShell examples before or equally with CLI unless there is a clear need, as CLI is more universally accessible.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by primarily referencing Azure PowerShell scripts and commands for migration and preview registration, with no mention of Linux or cross-platform alternatives such as Azure CLI (bash) or ARM templates. The only command-line examples provided use PowerShell cmdlets, and the migration script is specifically described as an Azure PowerShell script. There are no Linux shell/bash examples, and the documentation does not explicitly mention Linux or macOS compatibility for these operations.

Recommendations:

Provide equivalent Azure CLI (bash) examples for all PowerShell commands, especially for registration, unregistration, and migration tasks.
Mention that Azure CLI is cross-platform and can be used from Linux, macOS, and Windows.
If a migration script is only available in PowerShell, clarify whether it can be run on PowerShell Core (pwsh) on Linux/macOS, or provide a CLI/ARM/Bicep alternative.
Include links or references to documentation on using Azure Application Gateway with Linux-based tools and environments.
Ensure that tutorials and next steps include both PowerShell and CLI options, and avoid defaulting to Windows-centric tools.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ powershell_heavy

Summary:

The documentation, while claiming support for both Windows and Linux, demonstrates a Windows-first bias in several areas. Windows-specific concepts (such as registry keys, Windows services, and file paths) are described in detail, often without equivalent Linux examples or explanations. Query and alerting examples frequently use Windows file paths and services before mentioning Linux equivalents, and the registry section is entirely Windows-focused. The documentation also references Windows tools and patterns (e.g., PowerShell, Windows registry, Windows services) more prominently and in greater detail than Linux alternatives. Linux coverage is present but less detailed and often secondary.

Recommendations:

Provide equivalent Linux examples and explanations wherever Windows-specific features (like registry or services) are discussed. For example, explain Linux alternatives to registry tracking (such as configuration file monitoring) and daemon/service management.
Balance the order of examples and explanations so that Linux and Windows are treated equally (e.g., alternate which OS is mentioned first in tables, examples, and queries).
Expand Linux-specific guidance, such as common file paths, daemon/service management, and package/software tracking, to match the depth given to Windows.
Include Linux-specific alerting and query scenarios, such as monitoring /etc/hosts, /etc/passwd, or systemd service changes, alongside Windows examples.
Where PowerShell or Windows tools are referenced, provide equivalent Linux command-line or scripting examples (e.g., Bash, systemctl, journalctl).

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a bias toward Windows environments by exclusively providing PowerShell commands for resource cleanup and focusing on IIS (a Windows web server) for validation. There are no Linux-specific examples, such as using Bash, Azure CLI, or deploying Linux-based web servers (e.g., Apache or Nginx) for testing the Application Gateway. The instructions and screenshots are tailored to Windows-centric workflows.

Recommendations:

Provide equivalent Azure CLI and Bash commands for resource cleanup, such as 'az group delete --name <resource group name>'.
Include examples of deploying Linux-based VMs with Apache or Nginx for backend validation, alongside IIS.
Offer validation steps using Linux tools (e.g., curl, wget) to test the Application Gateway.
Ensure screenshots and instructions are platform-neutral or include both Windows and Linux perspectives.
Explicitly mention that the template and process work for both Windows and Linux VMs, and link to Linux-specific quickstarts where relevant.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

Summary:

The documentation provides both Azure CLI and PowerShell examples for managing access restrictions, but PowerShell examples are often presented first and are more detailed in advanced scenarios. There are no explicit Linux shell (bash) or platform-specific examples outside of Azure CLI, and PowerShell is emphasized, which is more familiar to Windows users. No Windows-only tools are mentioned, but the prominence and order of PowerShell content may signal a subtle Windows bias.

Recommendations:

Ensure that Azure CLI examples are always presented before or alongside PowerShell examples, as Azure CLI is cross-platform and more familiar to Linux users.
Where advanced scenarios are demonstrated with PowerShell, provide equivalent Azure CLI examples (e.g., for multi-source rules and HTTP header filtering).
Explicitly mention that all CLI commands work on Linux, macOS, and Windows, and clarify when PowerShell is required versus when Azure CLI suffices.
Consider adding bash shell script examples for common tasks, especially where scripting is discussed.
Review screenshots and UI instructions to ensure they are not Windows-centric (e.g., avoid showing only Windows browser UI if possible).

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation page focuses exclusively on assessing ASP.NET web apps, implicitly assuming a Windows environment. There are no examples, tools, or guidance specific to Linux-based .NET web apps. The linked resources and terminology (ASP.NET, App Service) are historically Windows-centric, and there is no mention of Linux assessment workflows or parity.

Recommendations:

Include explicit guidance or examples for assessing .NET web apps running on Linux (e.g., ASP.NET Core on Linux).
Mention any differences or additional considerations for Linux-hosted .NET apps in the assessment process.
Provide links to Linux-specific documentation or tools, if available.
Clarify whether the assessment process supports both Windows and Linux workloads, and highlight any platform-specific limitations.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows-first bias by referencing the Windows deployment path (C:\home\site\wwwroot) before mentioning the Linux equivalent, and by only providing a Windows example for the config file path. The Linux path is mentioned only in a note, and there are no Linux-specific examples or screenshots. There are no PowerShell-specific commands or Windows-only tools, but the documentation implicitly assumes Windows as the default platform.

Recommendations:

Provide both Windows and Linux file path examples side by side when referencing deployment directories (e.g., 'C:\home\site\wwwroot' for Windows and '/home/site/wwwroot' for Linux).
Instruct users on how to locate or deploy the configuration file on both Windows and Linux environments.
Include a Linux-specific example for the 'platform.configFilePath' setting in the main instructions, not just in a note.
Add a table or section explicitly comparing Windows and Linux behaviors for file-based configuration.
Ensure that all platform-specific differences are clearly documented and that neither platform is treated as the implicit default.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation assumes configuration is performed exclusively through the Azure Portal GUI, which is a web-based tool accessible from any OS, but does not provide any command-line examples. There are no CLI (Azure CLI, Bash, or PowerShell) instructions, but the absence of Linux-specific (or cross-platform) command-line examples may disadvantage users who prefer or require automation or terminal-based workflows, which are especially common on Linux. There is also no mention of Linux-native tools or patterns.

Recommendations:

Add Azure CLI examples for configuring GitHub authentication, including commands to set up identity providers and manage secrets.
Include Bash shell command examples for Linux users, especially for scripting or automation.
Explicitly mention that all steps can be performed from any OS via the Azure Portal, but provide parity by showing how to accomplish the same tasks using cross-platform tools.
If PowerShell examples are added in the future, ensure Bash/Azure CLI equivalents are provided alongside.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation lists Windows hosting options and file/script types before Linux equivalents, and Windows-specific tools and scripts (.exe, .cmd, .bat, .ps1) are mentioned before Bash scripts and cross-platform scripting languages. This ordering and emphasis subtly prioritize Windows environments and tooling.

Recommendations:

Alternate the order of Windows and Linux hosting options, or list them together to avoid prioritization.
List Bash scripts (.sh) and cross-platform scripting languages before or alongside Windows-specific scripts to demonstrate equal support.
Explicitly mention Linux tools or patterns (e.g., cron jobs, shell environments) where relevant.
Add examples or notes highlighting parity and any differences in behavior or support between Windows and Linux environments.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page presents Windows containers first and provides more detail for Linux containers, but omits equivalent SSH/CLI instructions for Windows containers. The Linux section includes step-by-step CLI commands and example outputs, while the Windows section only mentions browser-based SSH and explicitly states that Azure CLI SSH sessions are not supported for Windows containers. There are no PowerShell or Windows-native SSH client examples, nor guidance for advanced Windows container access.

Recommendations:

Provide parity in example depth: If browser-based SSH is the only supported method for Windows containers, explicitly state this and explain the technical reasons. If there are alternative methods (e.g., PowerShell remoting, Windows SSH client), provide step-by-step instructions and examples as done for Linux.
Include Windows-native command-line examples: If possible, show how to use Windows tools (e.g., PowerShell, Windows SSH client) to connect to Windows containers, or clarify their limitations.
Balance section order: Consider alternating or combining Linux and Windows instructions for each scenario, or clearly indicate why one platform has more options.
Clarify feature parity: Add a comparison table summarizing which SSH access methods are available for Linux vs. Windows containers, so users can quickly see the differences.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a subtle Windows bias by referencing Windows first in the quickstart links and tabs, and by not providing explicit Linux-specific examples or instructions. While the content is generally cross-platform (using Python, Flask, and Azure CLI), there is a lack of parity in highlighting or demonstrating Linux workflows, especially in the setup and deployment sections.

Recommendations:

Ensure that all quickstart and setup links include both Windows and Linux tabs/examples, and that Linux is given equal prominence.
Explicitly mention and provide Linux-specific instructions or screenshots where platform differences exist (e.g., environment variable setup, file paths, deployment commands).
Where possible, use neutral, cross-platform language and tools (such as Azure CLI and VS Code) and avoid defaulting to Windows-first terminology or ordering.
Add a section or callout for common Linux deployment scenarios, such as using Bash scripts, systemd for service management, or Linux-specific troubleshooting tips.
Review and update all referenced links to ensure Linux users are not redirected to Windows-centric instructions by default.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation assumes the use of GitHub Codespaces (a Linux-based environment) but does not provide any explicit Linux or cross-platform command-line examples or troubleshooting. While it avoids overt Windows-specific tools, it implicitly assumes a .NET development workflow that is most familiar to Windows users and does not mention Linux-specific considerations, such as running .NET apps locally on Linux, using Linux package managers, or alternative editors/terminals. The deployment and development instructions (e.g., 'dotnet run', 'azd up') are cross-platform, but there is no explicit guidance for Linux or macOS users, nor any mention of PowerShell or Windows-only tools. The documentation also refers to opening the app in a browser and navigating to URLs, which is generic but could be clarified for different OS environments.

Recommendations:

Explicitly state that the tutorial is cross-platform and works on Windows, Linux, and macOS.
Add a note or section with Linux/macOS-specific instructions for running the app locally, such as using the terminal, installing .NET SDK on Linux, and opening URLs from the command line.
Provide troubleshooting tips for common Linux/macOS issues (e.g., permissions, environment variables).
Mention that all CLI commands (dotnet, azd) are cross-platform and provide links to installation instructions for each OS.
If referencing editors or terminals, mention alternatives (e.g., VS Code, GNOME Terminal, Terminal.app) and not just Windows tools.
Include screenshots or terminal output from Linux/macOS environments where appropriate.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ windows_first

Summary:

The documentation demonstrates subtle Windows bias by referencing Azure App Service (which is traditionally associated with Windows hosting), mentioning NuGet packages (a Windows/.NET package manager) in the security section, and using terminology like 'App Service app' throughout. However, the code examples, setup, and deployment instructions are Linux-friendly (bash commands, Python, GitHub Codespaces), and there are no explicit PowerShell or Windows command-line instructions. Still, Windows-centric tools and patterns are mentioned before or instead of their Linux equivalents.

Recommendations:

Replace or supplement references to 'NuGet packages' with 'Python packages' or 'pip packages' in the security section, since the tutorial is Python-based.
Clarify that Azure App Service supports both Linux and Windows, and ensure examples and terminology are inclusive of both platforms.
If mentioning package management or dependency updates, provide Python (pip/requirements.txt) guidance before or alongside any .NET/NuGet references.
Review security best practices to ensure all recommendations are relevant to Python/Linux environments, not just Windows/.NET.
Avoid Windows-centric terminology unless the tutorial is specifically for Windows users; otherwise, provide cross-platform context.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates configuring environment-specific values in Azure App Configuration using an ASP.NET Core app. It references and builds upon a prior Windows-centric quickstart, uses only .NET/C# code examples, and instructs users to modify 'launchSettings.json' (a Visual Studio/Windows-centric file) for environment variables. There are no Linux-specific instructions, nor are cross-platform alternatives (such as setting environment variables via the shell) provided.

Recommendations:

Include instructions for setting environment variables on Linux/macOS (e.g., using export in bash/zsh) alongside the launchSettings.json method.
Clarify that 'launchSettings.json' is primarily used in Visual Studio and may not apply to all development environments.
Provide examples or notes for running the sample app on Linux/macOS, including any differences in file paths or commands.
Reference cross-platform .NET Core development practices, ensuring parity for non-Windows users.
Link to documentation on configuring environment variables in different operating systems.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ minor_missing_linux_example

Summary:

The documentation provides both Windows and Linux pivots for most steps, but the Windows instructions and examples are consistently presented before the Linux ones. In a few places, directory names and runtime versions differ slightly between pivots, but both platforms are generally covered. However, the 'platform-windows' pivot appears first, and some minor details (like directory names) are more explicit in the Windows section. There are no exclusive Windows tools (like PowerShell) or commands, and the Azure CLI is used throughout, which is cross-platform. The FAQ and troubleshooting sections are platform-neutral.

Recommendations:

Alternate the order of platform pivots so that Linux is sometimes presented first, or present both pivots in parallel/tabs to avoid implicit prioritization.
Ensure that directory names and runtime versions are consistent and clearly explained for both platforms.
Explicitly state that all Azure CLI commands work identically on Windows, Linux, and macOS, to reinforce parity.
Consider adding a brief note at the top acknowledging cross-platform support and that instructions are available for both Windows and Linux.
Review for any subtle differences in instructions or terminology that may unintentionally favor Windows, and harmonize where possible.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

Summary:

The documentation provides environment variable setup instructions for Windows Command Prompt and PowerShell before mentioning the equivalent commands for macOS/Linux. Both Windows and Linux/macOS are covered, but Windows instructions are consistently presented first and PowerShell is explicitly called out, which may signal a subtle Windows-first bias.

Recommendations:

Alternate the order in which Windows and Linux/macOS instructions are presented, or present them in parallel (side-by-side tabs or tables) to avoid implying priority.
Avoid giving Windows-specific instructions (e.g., setx, PowerShell) more prominence than Linux/macOS equivalents.
Consider using tabs or collapsible sections for each OS to provide equal visibility.
Explicitly state that all major platforms are supported and that the instructions are equivalent.
Where possible, provide cross-platform commands (e.g., using a tool like cross-env or platform-agnostic scripts) or note any platform-specific caveats.

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation presents both Windows and Linux default values in a configuration table, but consistently lists Windows defaults before Linux. There are no explicit examples or instructions that are Windows-specific (such as PowerShell commands or Windows-only tools), nor are there missing Linux examples. However, the ordering in the table and some notes (such as limitations and feature support) mention Windows first or focus on Windows-specific limitations.

Recommendations:

List Linux and Windows defaults in a neutral order, or alternate which is listed first.
Where platform-specific limitations or behaviors are mentioned, ensure both Windows and Linux are addressed equally, or clarify if only one is affected.
If there are platform-specific configuration steps, provide examples for both Windows and Linux, or clarify when steps are identical.
Consider adding a summary table or section explicitly comparing Windows and Linux behaviors for clarity.

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation page lists .NET and ASP.NET Core providers first in the table of configuration provider libraries, with their samples and release notes prominently featured before Java, Python, JavaScript, and Go equivalents. This ordering may implicitly prioritize Windows-centric technologies, as .NET and ASP.NET Core are most commonly associated with Windows environments, even though they are now cross-platform. There are no explicit Windows-only tools or PowerShell examples, and Linux is not mentioned or omitted in examples, but the ordering and emphasis suggest a subtle Windows/.NET-first bias.

Recommendations:

Reorder the provider libraries table to alternate or group by language family or platform neutrality, rather than leading with .NET/Windows-centric stacks.
Explicitly mention cross-platform compatibility for .NET and ASP.NET Core providers to clarify that they are not Windows-only.
Add a note or section highlighting Linux and container-native usage patterns, especially for Java, Python, Go, and JavaScript stacks.
Ensure that future documentation and samples include Linux-specific instructions or examples where relevant, such as environment variable configuration, CLI usage, or deployment scenarios.

Create pull request

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