1531
Pages Scanned
46
Pages Flagged
1531
Changed Pages
3.0%
% Pages Flagged

Scan Information

Started At: 2025-09-15 00:00:08

Finished At: 2025-09-15 00:32:58

Status: completed

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

Current Phase: discovery

Problematic Pages

Bias Types:
⚠️ powershell_heavy
⚠️ missing_linux_example
⚠️ windows_tools
Summary:
The documentation provides only a PowerShell script example for programmatically accessing Azure AD B2C audit logs, with no equivalent example for Linux or cross-platform environments (such as Bash with curl or Python). The script assumes the use of PowerShell, which is natively available on Windows and Azure Cloud Shell, but not on most Linux distributions by default. No mention is made of Linux tools or alternative scripting approaches, and the only automation example is Windows-centric.
Recommendations:
  • Add a Bash (curl/jq) example for querying the Microsoft Graph API and saving audit logs, suitable for Linux and macOS users.
  • Provide a Python example script for cross-platform compatibility.
  • Explicitly mention that PowerShell Core is available for Linux and macOS, and provide installation instructions or a note about this.
  • Ensure that automation and scripting guidance is not limited to Windows/PowerShell, and that Linux-first or cross-platform approaches are equally represented.
  • Where possible, use generic HTTP request examples (e.g., with curl or HTTPie) alongside PowerShell to ensure parity.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ powershell_heavy
⚠️ windows_tools
⚠️ missing_linux_example
Summary:
The documentation page demonstrates subtle Windows bias primarily through its references and linked examples. PowerShell is mentioned as the tool for connecting virtual networks, and there are no equivalent CLI or Linux-native examples provided. The documentation refers to Azure portal UI and PowerShell operations, but does not mention or link to Azure CLI, Bash, or Linux-oriented workflows. This may make the documentation less accessible or immediately actionable for Linux users.
Recommendations:
  • Provide parallel Azure CLI (az) examples alongside PowerShell for all network configuration and management tasks.
  • Include references and links to Linux/Bash-based workflows where possible, especially for common operations like connecting virtual networks or applying network configurations.
  • When mentioning PowerShell or Windows tools, ensure Linux equivalents are mentioned with equal prominence and, where possible, before or alongside Windows examples.
  • Add explicit notes or sections for Linux users, clarifying any differences or additional steps required.
  • Review related content and ensure that for every PowerShell or Windows-centric guide, a CLI or cross-platform alternative is linked.
GitHub Create pull request
Bias Types:
⚠️ windows_tools
⚠️ windows_first
⚠️ missing_linux_example
Summary:
The documentation page is generally platform-neutral but contains a few instances of Windows bias. It references Windows-specific tools and services (such as Windows Update, Windows Defender, and KMS activation for Windows VMs) without mentioning Linux equivalents or providing guidance for Linux-based deployments. Additionally, the only explicit mention of a management endpoint is for the Azure portal and PowerShell, with no mention of Azure CLI or other cross-platform tools. There are no Linux-specific examples or considerations, and Windows-related configurations are discussed without Linux parity.
Recommendations:
  • When referencing management endpoints, mention Azure CLI alongside PowerShell to provide cross-platform guidance.
  • For sections discussing Windows-specific services (e.g., KMS, Windows Update, Windows Defender), add notes or links about Linux equivalents (such as Linux VM activation, update mechanisms, and security tools) or clarify if these steps are not required for Linux.
  • Include examples or notes for Linux-based deployments where relevant, especially in sections about VM configuration and network requirements.
  • Ensure that any scripts or command-line instructions are provided for both Windows (PowerShell) and Linux (Bash/Azure CLI) where applicable.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ powershell_heavy
⚠️ windows_tools
⚠️ missing_linux_example
Summary:
The documentation demonstrates a Windows bias by presenting Windows information and tools before Linux equivalents, providing a PowerShell automation example but omitting a Bash/Linux shell script, and referencing Windows-specific patterns. Linux is mentioned, but Linux-specific automation and command-line examples are underrepresented.
Recommendations:
  • Provide Linux shell (bash) script examples alongside PowerShell for automation tasks.
  • Present Linux and Windows information in parallel or in a neutral order, rather than Windows-first.
  • Include examples and guidance for Linux container scenarios, especially since Premium V4 supports Linux custom containers.
  • Reference cross-platform tools and workflows (e.g., Azure CLI, bash) before or alongside Windows-specific tools.
  • Clarify any differences in steps or options for Linux users, especially where the Azure portal or CLI experience may differ.
GitHub Create pull request
Bias Types:
⚠️ powershell_heavy
⚠️ windows_tools
⚠️ missing_linux_example
⚠️ windows_first
Summary:
The documentation exhibits a Windows bias by providing PowerShell scripts as the only automation example for identifying impacted Traffic Manager endpoints, referencing PowerShell as the primary scripting tool, and not offering equivalent Bash or cross-platform CLI scripts. Additionally, when linking to external scripts, only PowerShell solutions are mentioned, and there is no mention of Linux or macOS-specific workflows or tools. While Azure CLI and REST API references are present, the only concrete automation example is PowerShell-based, and PowerShell is mentioned before any cross-platform alternatives.
Recommendations:
  • Provide equivalent Bash or Azure CLI scripts for all PowerShell examples, especially for identifying Traffic Manager endpoints and retrieving site configuration details.
  • Explicitly mention that PowerShell scripts can be run on Linux and macOS using PowerShell Core, or provide alternative instructions for those platforms.
  • Where automation is discussed, offer both Windows (PowerShell) and Linux/macOS (Bash/CLI) options side by side.
  • Reference cross-platform tools and workflows (such as Azure CLI, Bash, or Python scripts) equally or before Windows-specific tools.
  • Add a note clarifying the cross-platform compatibility of all scripts and tools mentioned, and avoid assuming a Windows-only environment.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ windows_tools
⚠️ missing_linux_example
Summary:
The documentation contains a section on server-level authorization that is explicitly labeled as 'Windows apps only' and provides detailed instructions for configuring IIS via web.config, which is not applicable to Linux. There is no equivalent example or guidance for Linux-based apps, and the documentation does not mention Linux alternatives or patterns for fine-grained authorization at the server level. Additionally, the use of 'Windows apps only' and IIS/web.config patterns before any Linux discussion demonstrates a Windows-first approach.
Recommendations:
  • Provide equivalent examples or guidance for Linux-based App Service apps, such as using middleware in popular frameworks (e.g., Express.js for Node.js, Flask/Django for Python, etc.) to implement authorization.
  • Explicitly mention that Linux apps require a different approach and link to relevant documentation or samples for Linux-based authorization patterns.
  • Consider reordering or clearly separating Windows-only and cross-platform guidance to avoid implying that Windows is the default or primary platform.
  • Where possible, include both Windows and Linux examples side by side when discussing platform-specific configuration.
GitHub Create pull request
Bias Types:
⚠️ missing_linux_example
⚠️ windows_tools
⚠️ powershell_heavy
Summary:
The documentation page demonstrates a bias toward Windows environments by providing only a C# example using the Microsoft.IdentityModel.Tokens NuGet package (commonly used in Windows/.NET development) for generating the client secret JWT. There are no Linux/Unix command-line examples (such as using OpenSSL or Python), and no mention of cross-platform tools or scripting languages. The documentation assumes familiarity with Windows-centric development tools and omits guidance for Linux users.
Recommendations:
  • Add Linux-friendly examples for generating the client secret JWT, such as using OpenSSL, Python (PyJWT), or Node.js (jsonwebtoken).
  • Explicitly mention that the client secret can be generated on any platform, and provide at least one cross-platform, command-line example.
  • Reference open-source, cross-platform libraries and tools in addition to the Microsoft.IdentityModel.Tokens NuGet package.
  • Include sample shell commands or scripts that Linux/macOS users can run to accomplish the same tasks.
  • Ensure that any instructions for configuring application settings or files are not specific to Windows file paths or tools.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ powershell_heavy
⚠️ windows_tools
⚠️ missing_linux_example
Summary:
The documentation demonstrates a moderate Windows bias. Windows-specific instructions, tools, and examples (such as PowerShell and Windows paths) are often presented before or in greater detail than their Linux counterparts. Some advanced configuration sections (like customizing memory, CPU, and health ping) provide PowerShell and Windows-centric details, while Linux-specific equivalents are less detailed or missing. Windows tools and patterns (e.g., Kudu, IIS, .NET Framework, Windows file paths) are referenced more frequently and with more depth. Linux examples are present, but sometimes as an afterthought or with less coverage.
Recommendations:
  • Ensure parity between Windows and Linux sections by providing equally detailed Linux examples and explanations for all advanced configuration topics (e.g., memory, CPU, health checks).
  • When showing both Bash and PowerShell commands, present Bash (Linux) examples first or side-by-side, not always after PowerShell.
  • Expand Linux-specific troubleshooting and diagnostic instructions to match the depth of Windows/Kudu coverage.
  • Where Windows-specific tools (like Kudu, IIS, .NET Framework) are mentioned, provide Linux analogs or clarify their applicability.
  • Audit for missing Linux examples (e.g., verifying CPU/memory limits inside Linux containers) and add them.
  • Avoid assuming Windows file paths or conventions in general explanations; use neutral or dual examples.
  • Review all sections for balance in terminology and depth, ensuring Linux users receive equivalent guidance.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ missing_linux_example
⚠️ windows_tools
Summary:
The documentation exhibits a Windows bias by explicitly stating that gateway-required virtual network integration is only supported for Windows plans, with Linux apps being unsupported. All troubleshooting and connectivity examples use Windows-centric tools and commands (e.g., PowerShell's Test-NetConnection, netstat -aon), with no equivalent Linux instructions or examples. There is no mention of Linux-compatible approaches or tools, and the documentation does not provide parity for Linux users.
Recommendations:
  • Clearly state early in the documentation that gateway-required virtual network integration is not supported for Linux apps, and provide guidance or links for Linux users to alternative solutions (such as regional virtual network integration).
  • Where troubleshooting steps are provided (e.g., using PowerShell's Test-NetConnection or netstat), offer equivalent Linux commands (such as nc, curl, or ss) alongside the Windows examples.
  • If possible, provide a table or section comparing feature support and troubleshooting steps for both Windows and Linux App Service plans.
  • Ensure that any references to tools or commands (e.g., tcpping, netstat) include both Windows and Linux usage, or clarify if a tool is only available on one platform.
  • In sections where only Windows portal UI or workflow is described, clarify if the same or similar options exist for Linux, or explicitly state if not applicable.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ missing_linux_example
⚠️ windows_tools
Summary:
The documentation demonstrates a Windows bias by focusing on Windows-based deployment and configuration patterns for ASP.NET apps. Examples for listing .NET Framework versions use Windows file paths and Kudu's CMD/PowerShell consoles, with no Linux equivalents or mention of Linux-based App Service environments. The use of Visual Studio and Windows-specific deployment tools is emphasized, and Linux scenarios are only referenced in passing or as exceptions.
Recommendations:
  • Add explicit examples and instructions for configuring and deploying ASP.NET apps on Linux-based App Service plans, including how to check .NET versions and access environment variables.
  • Provide Linux shell (bash) equivalents for commands currently shown only in CMD/PowerShell, especially for listing installed .NET versions.
  • Mention Linux tools and workflows (such as SSH, bash, or Linux-based deployment pipelines) alongside Windows tools, not just as a footnote.
  • Clarify which instructions apply to Windows App Service plans and which to Linux, and provide parity in guidance for both.
  • Include screenshots or walkthroughs for Linux-based App Service environments where relevant.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ windows_tools
⚠️ powershell_heavy
⚠️ missing_linux_example
Summary:
The documentation generally provides parity between Windows and Linux by using platform pivots. However, there are several sections where Windows-specific tools and patterns (such as KuduScript, directory paths, and deployment script customization) are described in detail for Windows, while the Linux equivalents are either less detailed, missing, or require more manual steps. Windows examples and tools (like KuduScript and .dll extensions) are often described first or in more depth, and some automation patterns (custom deployment scripts for Composer, Bower, Gulp, Grunt) are only described for Windows. Linux users are sometimes directed to use manual shell commands or edit configuration files directly, with less guidance on automation or parity with Windows tooling.
Recommendations:
  • Ensure that all deployment automation examples (such as running Composer, Bower, Gulp, Grunt) are provided for Linux as well, not just Windows. If KuduScript or similar tooling is not available for Linux, suggest or document equivalent approaches (such as custom Oryx build hooks or startup scripts).
  • Where Windows-specific tools or patterns are mentioned (e.g., KuduScript, .dll files, Windows directory paths), provide Linux equivalents immediately alongside or before the Windows examples.
  • Expand the Linux sections to include more detailed, step-by-step automation and scripting guidance, matching the depth provided for Windows.
  • Avoid assuming that users are familiar with manual shell editing (e.g., using echo to create .ini files); suggest or document more user-friendly alternatives if available.
  • Review the order of presentation to ensure Linux is not always secondary to Windows, especially in cross-platform documentation.
  • Where possible, provide a summary table or section that highlights differences and similarities between Windows and Linux approaches, to help users quickly find relevant guidance.
GitHub Create pull request
Bias Types:
⚠️ powershell_heavy
⚠️ windows_tools
⚠️ windows_first
⚠️ missing_linux_example
Summary:
The documentation page demonstrates a Windows bias by emphasizing Windows-centric tools and workflows such as Azure PowerShell, Visual Studio, and the App Service migration assistant for PowerShell scripts. These tools are either exclusive to Windows or primarily used in Windows environments. Linux-native deployment methods, such as Bash scripting or Linux CLI workflows, are not mentioned or exemplified. Visual Studio Code is listed, but its example is focused on .NET, which is also traditionally Windows-centric. There are no explicit Linux shell or cross-platform examples, and Windows tools are often mentioned before or instead of Linux alternatives.
Recommendations:
  • Include Linux shell (Bash) and cross-platform CLI examples alongside or before PowerShell examples.
  • Highlight cross-platform tools (such as Azure CLI) with explicit Linux usage scenarios.
  • Add references to Linux-native editors (such as Vim, Emacs) or deployment workflows (e.g., SCP, rsync, Git from Linux).
  • Provide parity in documentation for Linux users, such as migration tools or scripts that run natively on Linux.
  • Ensure that Visual Studio Code examples include non-.NET languages and Linux deployment scenarios.
  • Where PowerShell is referenced, also provide equivalent Bash or shell script guidance.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ missing_linux_example
⚠️ windows_tools
⚠️ powershell_heavy
Summary:
The documentation page demonstrates a moderate Windows bias. While it mentions both Linux and Windows App Service options, several examples and explanations are Windows-centric. Notably, the Web Deploy scenario is only shown with a Windows agent, and troubleshooting focuses on Windows-specific issues. There is a lack of Linux-specific deployment examples, and Windows tools and patterns (such as Web Deploy and IIS references) are mentioned without Linux equivalents or alternatives.
Recommendations:
  • Provide explicit Linux deployment examples, especially for scenarios where only Windows (e.g., Web Deploy) is currently covered.
  • When mentioning deployment methods or tools (such as Web Deploy), clarify their platform limitations and suggest Linux alternatives (e.g., ZIP deploy, FTP, or Kudu REST API for Linux).
  • Balance troubleshooting and FAQ sections by including common Linux agent issues and solutions, not just Windows-specific errors.
  • In code samples and agent selection, alternate or parallelize examples for both 'windows-latest' and 'ubuntu-latest' where possible, especially in YAML snippets.
  • Avoid assuming IIS or Windows-specific configuration (such as web.config or iisnode) unless clearly marked as Windows-only, and provide Linux equivalents or note their absence.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ missing_linux_example
⚠️ windows_tools
Summary:
The documentation page exhibits a Windows-first bias in several areas. Kudu is described primarily in the context of Windows App Service, with Linux mentioned as a secondary consideration. Deployment mechanisms such as WebDeploy (a Windows-centric tool) are listed without Linux equivalents like SCP or rsync. There are no explicit Linux command-line or shell script examples, and the language-specific sections (e.g., .NET) do not clarify cross-platform differences or provide Linux-specific guidance. The diagnostic and troubleshooting steps are described only through the Azure Portal UI, which is platform-agnostic but omits any CLI-based alternatives that might be more familiar to Linux users.
Recommendations:
  • Provide Linux-specific deployment examples, such as using SCP, rsync, or SFTP for file transfers.
  • When mentioning Kudu, clarify its operation and differences on both Windows and Linux App Service environments.
  • Include Bash or shell script examples alongside any PowerShell or Windows command-line instructions.
  • List Linux-friendly deployment mechanisms and tools (e.g., Azure CLI, Git, rsync) alongside or before Windows-centric tools like WebDeploy.
  • In language-specific sections, note any differences in deployment or build processes between Windows and Linux App Service.
  • For diagnostics, offer Azure CLI or REST API alternatives to portal-based instructions, catering to users who prefer command-line tools.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ windows_tools
⚠️ missing_linux_example
Summary:
The documentation exhibits a mild Windows bias, primarily by referencing 'Windows apps' in the External Git section and not providing equivalent guidance or terminology for Linux-based apps. There is also a lack of explicit Linux or cross-platform command-line examples, and no mention of Linux-specific tools or workflows. The documentation assumes portal-based configuration and does not address parity for Linux users or provide CLI-based alternatives that are common in Linux environments.
Recommendations:
  • Replace or supplement 'For Windows apps, you can select External Git...' with inclusive language such as 'For apps not directly supported by the Azure portal (including Linux and Windows apps), you can select External Git...'.
  • Add explicit examples or notes for Linux-based App Service apps, including any differences in setup or deployment.
  • Provide cross-platform command-line examples (e.g., Azure CLI, Bash scripts) alongside portal instructions, especially for enabling/disabling continuous deployment.
  • Mention Linux-friendly tools and workflows (such as Bash, SSH, or Linux-based CI/CD runners) where relevant.
  • Ensure that screenshots and terminology do not imply Windows exclusivity, and clarify when instructions apply to all platforms.
GitHub Create pull request
Bias Types:
⚠️ powershell_heavy
⚠️ windows_first
⚠️ windows_tools
⚠️ missing_linux_example
Summary:
The documentation demonstrates a moderate Windows bias. PowerShell is given a dedicated section with detailed steps, and references to 'local PowerShell terminal' are made without Linux shell equivalents. The troubleshooting section includes error messages and resolutions that reference Windows-specific issues (e.g., Node.js native modules lacking Windows binaries). There is no explicit example or guidance for Linux users in sections where PowerShell is mentioned, and the order of presentation often places Windows/PowerShell before Linux/CLI. Additionally, the use of 'PowerShell' as a default local terminal and the lack of explicit Linux shell commands or screenshots further reinforce the bias.
Recommendations:
  • Add explicit Linux/Bash shell examples and instructions wherever PowerShell is referenced, especially in the 'Create and configure a Git-enabled app' section.
  • When referencing a 'local PowerShell terminal', also mention 'Bash' or 'Linux terminal' for parity.
  • Ensure that troubleshooting steps and error messages include Linux/macOS-specific guidance where applicable.
  • Alternate the order of CLI and PowerShell sections or provide a unified table of commands for both platforms.
  • Include screenshots or terminal output from Linux environments, not just Windows.
  • Review references to Windows-specific tools or issues (such as Node.js native module errors) and provide Linux/macOS equivalents or notes.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ windows_tools
⚠️ missing_linux_example
Summary:
The documentation exhibits a mild Windows bias. Windows-specific paths (e.g., D:\home\site\wwwroot) are mentioned first, and the Kudu UI (which is not supported on Linux) is described in detail before alternatives for Linux are suggested. The use of 'Advanced Tools' in the Azure portal (Kudu) is a Windows-centric workflow, and Linux-specific instructions or parity for certain features (like the Kudu UI) are absent. Some examples and notes reference Windows paths or behaviors before Linux equivalents, and there is limited explicit guidance for Linux users in these cases.
Recommendations:
  • When mentioning default paths, list Linux and Windows paths together or alternate the order to avoid always putting Windows first.
  • Clearly indicate feature parity or lack thereof for both Windows and Linux at the start of each section, not only in notes after the fact.
  • Provide Linux-specific alternatives or workflows (such as using FTP, Azure CLI, or Kudu API) in parallel with Windows/Kudu UI instructions, rather than as afterthoughts.
  • Where UI or tool support differs (e.g., Kudu UI not available on Linux), offer a step-by-step Linux-friendly alternative with equal prominence.
  • Use neutral language and examples (e.g., use /home/site/wwwroot as the canonical path in code snippets, or show both Windows and Linux paths where relevant).
GitHub Create pull request
Bias Types:
⚠️ powershell_heavy
⚠️ missing_linux_example
⚠️ windows_tools
Summary:
The documentation page exclusively provides Azure PowerShell examples and instructions for configuring Traffic Manager and App Service Environments, with no mention of equivalent CLI (az), Bash, or Linux-native workflows. The only automation and scripting guidance is Windows-centric, and references to 'PowerShell Azure Resource Manager Traffic Manager support' reinforce this bias. There are no Linux or cross-platform command-line examples, nor is there guidance for users who may prefer or require non-Windows tooling.
Recommendations:
  • Add equivalent Azure CLI (az) examples for all PowerShell commands, as Azure CLI is cross-platform and widely used on Linux and macOS.
  • Explicitly mention that all operations can be performed using Azure CLI or REST API, and provide links or references to those resources.
  • Where screenshots or instructions reference PowerShell or Windows tools, include parallel examples or notes for Linux/macOS users (e.g., Bash shell, terminal screenshots).
  • Review related content and links to ensure Linux-friendly documentation is referenced alongside PowerShell/Windows resources.
  • Consider including a section or callout box that highlights cross-platform options for automation and scripting.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ windows_tools
⚠️ missing_linux_example
Summary:
The documentation page exhibits a Windows-first bias, with several examples and details provided specifically for Windows scenarios (such as Windows Containers and Windows App Service plan SKUs) without equivalent Linux examples or parity. Windows tools and patterns (e.g., Visual Studio remote debugging, Web Deploy) are mentioned explicitly, while Linux-specific deployment or debugging tools are not discussed. There is also a lack of Linux container-specific subnet/IP address calculations or operational notes, and Linux deployment/networking scenarios are only briefly referenced.
Recommendations:
  • Provide equivalent Linux container subnet/IP address calculation examples, including any differences in IP usage or scaling behavior.
  • Include Linux-specific deployment and debugging port requirements (e.g., SSH, SFTP, or other relevant tools) alongside or in place of Windows tools like Visual Studio remote debugging and Web Deploy.
  • When listing App Service plan OS/SKU combinations, mention Linux SKUs and their standby/scale behaviors, not just Windows.
  • Ensure all examples and operational notes (such as those for Windows Containers) have Linux container counterparts or explicitly state if there are no differences.
  • Expand on Linux continuous deployment and network dependency scenarios, referencing relevant documentation and tools.
GitHub Create pull request
Bias Types:
⚠️ powershell_heavy
⚠️ windows_first
⚠️ missing_linux_example
⚠️ windows_tools
Summary:
The documentation page demonstrates a Windows bias by providing only PowerShell commands and examples for certificate management, referencing Windows-specific certificate stores (e.g., Cert:\LocalMachine\Root), and explicitly stating that private client certificates are only supported from custom code in Windows code apps. There are no Linux or cross-platform command-line examples, and Linux scenarios are not addressed.
Recommendations:
  • Include equivalent Linux/Bash/OpenSSL commands for generating and exporting certificates, alongside the PowerShell examples.
  • Clarify support for Linux-based App Service apps, and provide guidance or alternatives for Linux scenarios.
  • Reference Linux certificate store locations and how to manage certificates on Linux-based workers, if supported.
  • Avoid language that implies Windows is the default or only supported platform unless it is a strict technical limitation; if so, clearly state the limitation and provide alternatives or workarounds for Linux users.
  • Add a section or callout explicitly addressing Linux support and any differences in certificate handling.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ powershell_heavy
⚠️ windows_tools
⚠️ missing_linux_example
Summary:
The documentation page shows evidence of Windows bias, particularly in the .NET/ASP.NET section, where Windows tools such as Visual Studio and Azure PowerShell are listed before cross-platform or Linux-native tools. Some sections (notably .NET) mention Windows-specific tools without equal prominence for Linux alternatives. The 'Next step' callout also defaults to an ASP.NET example, which is typically associated with Windows. In contrast, other stacks (Java, Node.js, PHP) emphasize Linux or cross-platform workflows, but the Python section's quickstart links default to 'windows' tabs, and Linux/WSL/Unix-specific instructions are not always given equal visibility.
Recommendations:
  • For .NET/ASP.NET, ensure Linux and cross-platform tools (e.g., Visual Studio Code, CLI, Azure CLI) are listed before or alongside Windows-specific tools like Visual Studio and Azure PowerShell.
  • Provide explicit Linux/Unix/WSL examples and instructions wherever Windows or PowerShell commands are given, especially in quickstarts and deployment guides.
  • In the Python section, ensure quickstart links and tabs default to a neutral or Linux-first experience, or provide parallel instructions for both Windows and Linux.
  • Balance the 'Next step' callout by offering options for multiple stacks or explicitly including a Linux-based example.
  • Wherever Windows tools or patterns are mentioned, ensure their Linux equivalents are also referenced and easily discoverable.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ missing_linux_example
⚠️ windows_tools
Summary:
The documentation page demonstrates a Windows bias by repeatedly referencing 'Azure App Service on Windows pricing', omitting any mention of Linux-based App Service plans, and providing no Linux-specific guidance or examples. All screenshots and feature comparisons are Windows-centric, and there is no discussion of Linux-specific scaling considerations or parity.
Recommendations:
  • Include references and links to Azure App Service on Linux pricing and documentation alongside Windows equivalents.
  • Add explicit notes or sections describing any differences or additional steps when scaling Linux-based App Service plans.
  • Provide screenshots and examples that show the experience for Linux-based App Service plans in the Azure portal.
  • Ensure feature comparison tables and documentation cover both Windows and Linux App Service plans, highlighting any differences.
  • Mention Linux-specific scaling considerations, such as supported features, quotas, or limitations, if any.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ missing_linux_example
⚠️ windows_tools
Summary:
The documentation page demonstrates a Windows bias by providing more detailed coverage and exclusive features for Windows-based apps. Several diagnostic tools and features (such as Proactive CPU Monitoring, Proactive Auto-Healing, and Navigator) are explicitly marked as 'Windows apps only', with no equivalent Linux guidance or alternatives provided. Linux support is mentioned in passing, but Linux-specific diagnostics are less prominent and lack detailed examples or instructions.
Recommendations:
  • Provide Linux-specific examples and walkthroughs for each diagnostic tool, especially where features differ between Windows and Linux.
  • Clearly indicate feature parity or lack thereof for each tool, and suggest alternative troubleshooting steps for Linux where direct equivalents are unavailable.
  • Include Linux-first or at least Linux-equal sections, not just Windows-first, and ensure Linux diagnostic categories are as detailed as Windows ones.
  • Where a feature is Windows-only, offer a roadmap or workaround for Linux users, or link to relevant Linux troubleshooting documentation.
  • Add screenshots and step-by-step guides for Linux diagnostics, similar to those provided for Windows.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ windows_tools
⚠️ missing_linux_example
Summary:
The documentation page exhibits a Windows-first bias. File paths and folder structures are described exclusively using Windows conventions (e.g., D:\home), and there is no mention of Linux equivalents or examples. Tools and features (such as Kudu/SCM) are referenced in a Windows-centric manner, and the only site extension suggested for disk usage is Azure Web Apps Disk Usage, which is tailored for Windows environments. There are no Linux command-line examples or references to Linux file system paths, and Linux/container scenarios are only mentioned as unsupported or as exceptions.
Recommendations:
  • Provide parallel Linux examples and file paths (e.g., /home/site/wwwroot) alongside Windows paths.
  • Include Linux-specific instructions or notes where behaviors differ, especially for containerized and Linux App Service environments.
  • Reference or suggest Linux-compatible tools for tasks such as disk usage analysis.
  • Clarify which features and instructions apply to Windows, Linux, or both, ideally with a comparison table.
  • When mentioning unsupported scenarios (e.g., Linux containers), provide links to alternative solutions or documentation for those environments.
GitHub Create pull request
Bias Types:
⚠️ powershell_heavy
⚠️ windows_tools
⚠️ windows_first
⚠️ missing_linux_example
Summary:
The documentation demonstrates a Windows bias by providing extensive Azure PowerShell examples and referencing PowerShell-specific modules and commands. PowerShell is a Windows-centric tool, and there are no equivalent Linux shell (bash) or cross-platform scripting examples. In several places, PowerShell instructions are given before or in more detail than Azure CLI, and there is no mention of Linux-specific tools or patterns. The documentation lacks explicit Linux shell (bash) or cross-platform scripting examples, which may disadvantage Linux users.
Recommendations:
  • Add bash (Linux shell) examples for all command-line operations, especially for token retrieval and identity management.
  • Ensure Azure CLI examples are complete and presented before or alongside PowerShell examples, as Azure CLI is cross-platform.
  • Avoid using PowerShell-specific syntax or modules in generic command-line examples; provide alternatives where possible.
  • Explicitly mention that all Azure CLI commands work on Linux, macOS, and Windows, and provide sample shell scripts for Linux users.
  • Where PowerShell is referenced, clarify its availability on Linux and macOS, or provide equivalent bash commands.
  • Audit for any references to Windows-only tools or patterns and provide Linux/macOS equivalents.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ powershell_heavy
⚠️ windows_tools
Summary:
The documentation page shows mild Windows bias. While it states that private endpoints are available for both Windows and Linux apps, the related content and quickstart links list Azure PowerShell before CLI, and there is no explicit mention of Linux-specific tools or examples. The documentation references Kudu/scm endpoints and FTP, which are more commonly associated with Windows workflows. There are no Linux shell or scripting examples, and the only command-line example shown is Azure CLI, which is cross-platform, but PowerShell is given equal prominence in the quickstart links.
Recommendations:
  • Ensure that Linux-specific examples or notes are included where relevant, such as mentioning SSH access or Linux-based deployment tools.
  • When listing quickstarts or scripts, list Azure CLI before PowerShell, as CLI is more cross-platform and widely used on Linux.
  • Include explicit Linux shell (bash) examples alongside PowerShell where scripting is demonstrated.
  • Clarify that Kudu/scm and FTP workflows are available for both Windows and Linux, or provide Linux-specific alternatives (e.g., SFTP, SSH).
  • Add a section or note on how to perform private endpoint configuration and troubleshooting from a Linux environment.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ windows_tools
⚠️ powershell_heavy
⚠️ missing_linux_example
Summary:
The documentation demonstrates some Windows bias, particularly in the Visual Studio Code (VS Code) deployment workflow. Windows-specific steps and tools (such as web.config, Application Insights, and resource group/App Service plan creation) are described in more detail and with more steps than their Linux counterparts. The Windows deployment instructions are more prominent and elaborate, and certain troubleshooting notes (e.g., about web.config) are only mentioned for Windows. There is also a reliance on Visual Studio Code, which is more common on Windows, and some steps reference Windows-centric patterns (e.g., 'right-click', 'Application Settings'). While Linux is supported and examples are present, parity in depth and troubleshooting is lacking. CLI and Portal instructions are more neutral, but the VS Code workflow leans Windows-first.
Recommendations:
  • Ensure that Linux deployment instructions are as detailed as Windows, including troubleshooting tips and common issues (e.g., what to do if the app doesn't start, or how to handle environment variables).
  • Provide Linux-specific notes where Windows-specific notes are given (e.g., if web.config is needed for Windows, clarify what Linux expects instead, such as package.json start scripts).
  • Balance the order and prominence of Linux and Windows instructions—avoid always presenting Windows as the 'advanced' or default path.
  • Where possible, use cross-platform terminology and avoid patterns that are only familiar to Windows users (e.g., 'right-click' could be 'context menu').
  • Include explicit Linux troubleshooting sections, especially for common deployment errors.
  • Mention and provide examples for Linux-native tools or workflows (e.g., using nano/vim for editing, or Linux file paths), not just VS Code.
  • Clarify when steps are identical for both OSes, and when they diverge, to help users understand platform-specific requirements.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ windows_tools
⚠️ missing_linux_example
⚠️ powershell_heavy
Summary:
The documentation exhibits a Windows-first bias in several areas. Windows-specific paths, tools, and terminology (such as 'D:\home', 'w3wp.exe', 'Web Deploy/MSDeploy', and references to Windows Communication Foundation) are mentioned before or instead of their Linux equivalents. Many examples and default values are given only for Windows, with Linux alternatives either missing, less detailed, or presented after the Windows information. Some features are described primarily in terms of Windows tooling and behaviors, with Linux support noted as an exception or afterthought.
Recommendations:
  • Provide Linux and Windows examples side by side for environment variable values, file paths, and configuration steps.
  • Ensure Linux-specific tools and behaviors (such as Oryx build automation, Linux file paths like '/home', and Linux container behaviors) are described with equal detail and prominence as Windows equivalents.
  • Avoid using Windows terminology (e.g., 'D:\home', 'w3wp.exe', 'applicationHost.config') without also providing the Linux equivalent or clarifying when it is Windows-only.
  • Where features or settings differ between Windows and Linux, clearly indicate the differences in a comparative table or callout, rather than describing Windows as the default and Linux as an exception.
  • Add Linux-specific troubleshooting steps, examples, and references (e.g., for log file locations, deployment methods, and runtime behaviors) wherever Windows-specific guidance is given.
  • Review and update references to Windows-only tools (such as MSDeploy, Web Deploy, and PowerShell scripts) to include Linux-friendly alternatives (such as SCP, rsync, Azure CLI, or bash scripts).
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ missing_linux_example
⚠️ windows_tools
Summary:
The documentation is heavily focused on Visual Studio and Windows-centric workflows, with all examples, screenshots, and instructions assuming the use of Visual Studio on Windows. There are no examples or guidance for Linux or cross-platform development environments, and all tooling (such as Server Explorer, Output window, and FTP via Windows Explorer) is Windows-specific. There is no mention of equivalent Linux tools or workflows, nor any parity for developers using VS Code, CLI, or non-Windows operating systems.
Recommendations:
  • Add equivalent instructions and screenshots for Linux and macOS users, including workflows using VS Code, Azure CLI, and cross-platform tools.
  • Provide examples for accessing logs, remote debugging, and file management using the Azure CLI, Kudu console, or FTP clients available on Linux/macOS.
  • Mention and link to cross-platform alternatives to Visual Studio features (e.g., VS Code Remote Debugging, Azure CLI log streaming, SFTP/FTP clients).
  • Clearly indicate which features are Windows-only and provide guidance for users on other platforms.
  • Reorganize sections to present cross-platform or CLI-based solutions before or alongside Windows/Visual Studio-specific instructions.
GitHub Create pull request
Bias Types:
⚠️ missing_linux_example
⚠️ windows_tools
⚠️ windows_first
Summary:
The documentation assumes a development environment based on GitHub Codespaces and .NET, which is cross-platform, but it implicitly favors Windows-centric workflows and tools. There are no explicit Linux or macOS terminal instructions, and the deployment and development steps (such as 'Open in Browser' and 'azd up') are described in a way that aligns more closely with Windows or Azure-centric environments. There is also a lack of explicit mention of Linux-native tools, shell commands, or alternative editors/terminals. The documentation does not provide parity for Linux users or acknowledge differences in workflow, such as using bash/zsh, local Linux development environments, or Linux package managers.
Recommendations:
  • Add explicit instructions for Linux and macOS users, including terminal commands and environment setup steps (e.g., using bash/zsh, dotnet CLI on Linux, and alternative editors).
  • Clarify that the steps work cross-platform and provide notes on any OS-specific differences, such as file paths, environment variable syntax, or browser opening commands.
  • Include examples of running and testing the app locally on Linux (e.g., using 'xdg-open' instead of 'Open in Browser', or noting how to access Swagger UI from a local browser).
  • Mention Linux package managers and installation steps for .NET SDK and Azure Developer CLI on Linux.
  • Ensure that all screenshots and UI references are either OS-neutral or include Linux/macOS variants where relevant.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ windows_tools
⚠️ powershell_heavy
Summary:
The documentation exhibits a mild Windows bias. Windows-specific instructions and examples are consistently presented before their Linux equivalents ("windows_first"). The use of Azure Cloud Shell and Azure CLI is mostly cross-platform, but there are references to Windows-specific tools and patterns, such as the use of the Azure portal's 'Advanced Tools' (Kudu), which is more commonly associated with Windows App Service. There is also a slight emphasis on Windows terminology and directory structures in the Windows section. However, both Windows and Linux instructions are provided, and there are no missing Linux examples.
Recommendations:
  • Alternate the order of Windows and Linux pivots in different sections to avoid always presenting Windows first.
  • Where possible, use neutral terminology and avoid referencing tools or features that are exclusive or more common on Windows (e.g., Kudu/Advanced Tools) without noting their Linux equivalents.
  • Ensure that all screenshots and walkthroughs are equally represented for both platforms, or provide platform-agnostic images.
  • Explicitly mention any differences in behavior or tooling between Windows and Linux App Service, rather than assuming parity.
  • Consider adding a summary table or section that highlights any platform-specific steps or caveats.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ windows_tools
⚠️ missing_linux_example
Summary:
The documentation page demonstrates a subtle Windows bias. Visual Studio Code (VS Code) is the only editor/IDE mentioned for local test running, and all GUI screenshots and instructions are from the Azure Portal web interface, which is platform-agnostic but often associated with Windows workflows. The .NET/NUnit example uses PowerShell syntax for package installation (dotnet add package), and the only editor integration described is for VS Code, with no mention of Linux-native editors or workflows. There are no explicit Linux shell examples (e.g., bash, zsh), and no mention of Linux-specific tools or environments. The documentation does not provide parity for Linux users in terms of editor/IDE or CLI workflow examples.
Recommendations:
  • Include explicit Linux shell (bash/zsh) examples for installing dependencies and running commands, especially for .NET/NUnit workflows.
  • Mention and provide examples for running Playwright tests in popular Linux editors (such as Vim, Emacs, or JetBrains IDEs) or at least clarify that VS Code is cross-platform.
  • Add notes or screenshots showing the experience on Linux systems, or clarify that all CLI commands and workflows are fully supported on Linux.
  • Where PowerShell or Windows-specific syntax is shown, provide the equivalent bash/zsh commands for Linux users.
  • Explicitly state that all steps are supported on Linux and macOS, and highlight any OS-specific considerations if they exist.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ powershell_heavy
Summary:
The documentation provides both Bash and PowerShell examples for all CLI commands, but consistently lists Bash first, followed by PowerShell. There is a strong focus on Azure CLI, which is cross-platform, but the presence of PowerShell-specific syntax and tabs throughout the document indicates a bias toward Windows users. No Linux-specific tools or patterns are missing, but the parity is maintained mainly through Bash examples, with no explicit mention of Linux environments or considerations.
Recommendations:
  • Explicitly mention that Bash examples are suitable for Linux/macOS users and PowerShell for Windows users.
  • Add a note in the prerequisites clarifying that the Azure CLI and all examples work on Linux, macOS, and Windows.
  • Include a brief section or callout highlighting any Linux/macOS-specific considerations (such as file permissions, line endings, or environment variable syntax differences, if applicable).
  • Ensure that any troubleshooting or advanced sections reference both Linux and Windows environments equally.
  • If possible, provide a single cross-platform script example using Azure CLI without OS-specific shell syntax, or link to such resources.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ missing_linux_example
Summary:
The documentation page demonstrates a Windows-first bias by exclusively providing instructions and examples using the Azure portal and Azure CLI, with command-line examples only shown using Azure CLI syntax (which is cross-platform but often associated with Windows environments). There are no explicit Linux-specific examples, nor are there any references to Linux tools or shell environments. Additionally, when suggesting utilities for DNS validation, only nslookup and dig are mentioned, but without explicit Linux or Windows context. There are no PowerShell-specific commands, but the absence of Linux shell or scripting examples and the reliance on the Azure portal (which is often presented from a Windows-centric perspective) further reinforce the bias.
Recommendations:
  • Explicitly mention that Azure CLI commands work on both Windows and Linux, and provide example shell commands for both Bash (Linux/macOS) and PowerShell (Windows).
  • Include Linux-specific command-line examples where appropriate, such as using curl or wget for API calls, and show equivalent commands in both Bash and PowerShell.
  • When referencing utilities like nslookup or dig, clarify their availability on both platforms and provide example outputs from both Windows and Linux environments.
  • Add a section or callout for users managing resources from Linux/macOS, highlighting any differences or additional steps (such as installing Azure CLI or required utilities).
  • Where possible, provide screenshots or terminal outputs from both Windows and Linux environments to ensure parity and inclusivity.
GitHub Create pull request
Bias Types:
⚠️ windows_tools
⚠️ missing_linux_example
Summary:
The documentation references Windows-specific tools (PowerShell) for backend management and omits mention of equivalent Linux/CLI tools. No Linux or cross-platform command-line examples are provided, and the only automation tool highlighted is PowerShell.
Recommendations:
  • Include Azure CLI examples alongside or instead of PowerShell for backend management tasks, as Azure CLI is cross-platform.
  • Mention that backend entities can also be managed using Azure CLI, and provide a link to relevant documentation.
  • Ensure that all tool references (e.g., PowerShell) are accompanied by their Linux/cross-platform equivalents.
  • Add a note clarifying that all management operations can be performed from Linux, macOS, and Windows using Azure CLI or REST API.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ missing_linux_example
Summary:
The documentation page is generally platform-neutral but contains a subtle Windows bias. Specifically, when discussing clearing the DNS cache, only the Windows command (`ipconfig /flushdns`) is mentioned, with no equivalent instructions for Linux or macOS. No PowerShell-specific commands or Windows-only tools are otherwise present, and the rest of the instructions are portal-based and cross-platform.
Recommendations:
  • When providing troubleshooting steps such as clearing the DNS cache, include equivalent commands for Linux (e.g., `sudo systemd-resolve --flush-caches` or `sudo resolvectl flush-caches`) and macOS (e.g., `sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder`).
  • Review other troubleshooting or automation sections to ensure parity in examples and instructions for Linux and macOS users.
  • If scripting or CLI automation is discussed, ensure that examples are provided for Bash (Linux/macOS) as well as PowerShell/Command Prompt (Windows), or clarify when instructions are cross-platform.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ windows_tools
Summary:
The documentation generally provides parity between Linux and Windows, offering separate sections and examples for both platforms. However, there are subtle signs of Windows bias: in the Application Insights section, the Windows-specific app setting (XDT_MicrosoftApplicationInsights_Java=1) is mentioned, and the use of the Kudu console (a Windows-centric tool) is specified for Windows, while SSH is used for Linux. In some cases, the Windows instructions reference tools or patterns (like Kudu) before or instead of Linux equivalents. The ordering of tabs sometimes places Windows before Linux, and the documentation occasionally assumes familiarity with Windows tools.
Recommendations:
  • Ensure that Linux and Windows instructions are presented with equal prominence and in a consistent order (e.g., always Linux first or alphabetical).
  • Where a Windows-specific tool (like Kudu) is mentioned, provide a brief explanation or a Linux equivalent (e.g., SSH, SFTP, or Azure CLI).
  • Clarify when certain app settings or environment variables are Windows-only, and provide Linux alternatives or explicitly state when not needed.
  • Review all examples and ensure that both Linux and Windows users have clear, step-by-step guidance using tools native to their platform.
  • Consider adding a summary table comparing platform-specific steps for quick reference.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ powershell_heavy
Summary:
The documentation provides both Azure CLI and Azure PowerShell instructions for verifying results, but the PowerShell tab is presented alongside the CLI tab without explicit Linux/bash examples. PowerShell is a Windows-centric tool, and its inclusion as a primary verification method can indicate a Windows bias, especially since no bash or Linux-native shell examples are given. The CLI examples use variable assignment syntax compatible with bash, but there is no explicit mention or guidance for Linux/macOS users, nor are there instructions for running these commands in a Linux environment.
Recommendations:
  • Explicitly state that the Azure CLI examples use bash syntax and are suitable for Linux/macOS as well as Windows (with WSL or Git Bash).
  • Add a dedicated 'Bash' or 'Linux/macOS' tab or section to clarify usage on non-Windows platforms.
  • Provide guidance for running Azure CLI commands in native Linux/macOS terminals.
  • If PowerShell is included, clarify that it is primarily for Windows users, and provide parity by ensuring bash/Linux examples are equally visible and complete.
  • Mention cross-platform compatibility of Terraform and Azure CLI, and link to platform-specific installation guides where appropriate.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ windows_tools
Summary:
The documentation provides cross-platform deployment examples for multiple languages, with most workflows running on Ubuntu (Linux). However, the ASP.NET (not Core) example is Windows-specific, using 'runs-on: windows-latest' and Windows-only tools (NuGet, MSBuild) without mentioning or providing Linux alternatives. Additionally, the ASP.NET section appears before Java, Node.js, and Python, potentially reinforcing a Windows-first impression for .NET developers.
Recommendations:
  • Provide a Linux-based example for ASP.NET (if feasible), or explicitly state that classic ASP.NET requires Windows runners due to MSBuild and NuGet dependencies.
  • Add a note clarifying platform requirements for each stack, especially where Windows is mandatory.
  • Where possible, mention cross-platform alternatives to Windows tools (e.g., dotnet CLI for .NET Core/5+).
  • Ensure that the order of sections does not imply Windows is the default or preferred platform for all stacks.
  • Consider adding a summary table indicating OS compatibility for each language/framework example.
GitHub Create pull request
Bias Types:
⚠️ windows_tools
⚠️ missing_linux_example
Summary:
The documentation references the Azure Tools for VS Code extension, which is primarily a GUI tool often associated with Windows workflows. There are no mentions of equivalent command-line or Linux-native approaches, nor are there alternative instructions for users on Linux or macOS.
Recommendations:
  • Include instructions for accessing Azure resources using command-line tools such as Azure CLI, which are cross-platform.
  • Mention how to install and use Azure Tools for VS Code on Linux and macOS, or provide alternative workflows for those platforms.
  • Provide parity by linking to documentation for both GUI and CLI-based Azure management.
  • Clarify that the instructions apply to all platforms, or specify any platform-specific steps if necessary.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ powershell_heavy
Summary:
The documentation presents both PowerShell and Azure CLI examples, but consistently lists PowerShell (a Windows-centric tool) before Azure CLI (cross-platform) in all code example tabs. There is no explicit mention of Linux or Bash, and no Linux-specific guidance or screenshots. The use of PowerShell as the first scripting example and the reference to Visual Studio (a Windows-preferred IDE) for enabling managed identity further reinforce a subtle Windows-first bias.
Recommendations:
  • Alternate the order of PowerShell and Azure CLI examples, or list Azure CLI first to reflect its cross-platform nature.
  • Explicitly mention that Azure CLI commands can be run on Linux, macOS, and Windows, and provide Bash shell context where appropriate.
  • Include Linux/Bash-specific notes or screenshots where UI differences exist.
  • Reference cross-platform editors (such as VS Code) alongside Visual Studio when discussing development environments.
  • Consider adding a short section or note highlighting parity and any differences for Linux users.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ missing_linux_example
Summary:
The documentation page exhibits mild Windows bias by referencing 'local cache for Windows apps' as a mitigation for cold starts, without mentioning an equivalent feature or guidance for Linux-based App Service apps. No Linux-specific tools, patterns, or examples are provided, and the only OS-specific advice is for Windows.
Recommendations:
  • Include equivalent guidance or features for Linux-based App Service apps, such as caching strategies or startup optimizations.
  • When mentioning OS-specific features (e.g., local cache for Windows), explicitly state whether there is a Linux equivalent or provide alternative recommendations for Linux users.
  • Add examples or notes that address both Windows and Linux scenarios where relevant, ensuring parity in operational guidance.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ powershell_heavy
Summary:
The documentation generally maintains good cross-platform parity, primarily using Azure CLI for setup and configuration, which is cross-platform. However, there is a subtle Windows bias in the dev environment setup section: Visual Studio for Windows is presented first and in more detail, while Visual Studio for Mac is noted as lacking integration. PowerShell is also mentioned as an option for authentication, but Linux-specific shells or tools (e.g., Bash, zsh) are not mentioned. There are no explicit Linux examples or screenshots, and the documentation does not highlight Linux-native development environments or workflows.
Recommendations:
  • Present cross-platform options in parallel or in a non-Windows-first order (e.g., group Visual Studio, VS Code, CLI, and PowerShell together, or rotate the order).
  • Include explicit Linux development environment instructions (e.g., using Bash/zsh, common Linux IDEs, or editors like JetBrains Rider or Eclipse).
  • Add a note or section confirming that all CLI commands work identically on Linux, macOS, and Windows, and provide example terminal commands for Linux/macOS users.
  • Where PowerShell is mentioned, also mention Bash/zsh as alternatives for Linux/macOS users.
  • Include screenshots or terminal output from Linux/macOS environments to reinforce parity.
  • Highlight any platform-specific caveats, if any exist, for Linux/macOS users.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ missing_linux_example
Summary:
The documentation is generally platform-neutral, focusing on Azure Portal UI steps. However, in the troubleshooting section, only a Windows-specific command (`ipconfig /flushdns`) is provided for clearing the DNS cache, with no mention of Linux or macOS equivalents. This presents a subtle 'windows_first' and 'missing_linux_example' bias.
Recommendations:
  • When providing troubleshooting steps that involve OS-level commands (such as clearing DNS cache), include equivalent instructions for Linux (e.g., `sudo systemd-resolve --flush-caches` or `sudo resolvectl flush-caches`) and macOS (e.g., `sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder`).
  • Explicitly state that the command given is for Windows, and offer parity for other major platforms.
  • Review future documentation for similar platform-specific troubleshooting tips and ensure cross-platform coverage.
GitHub Create pull request
Bias Types:
⚠️ windows_first
Summary:
The documentation generally avoids OS-specific bias, but in the section about editing the hosts file for DNS testing, the Windows path is listed before the Linux/macOS path. No PowerShell-specific examples, Windows-only tools, or missing Linux examples are present.
Recommendations:
  • When mentioning file paths or commands relevant to multiple platforms, alternate the order (e.g., list Linux/macOS before Windows in some cases) or present them in parallel (e.g., 'On Windows: ...; On Linux/macOS: ...').
  • Where possible, provide explicit examples for both Windows and Linux/macOS, especially for common administrative tasks.
  • Consider including screenshots or command-line snippets for both platforms if UI or CLI steps are shown elsewhere.
GitHub Create pull request
Bias Types:
⚠️ windows_first
Summary:
The documentation presents default values for DNS configuration with 'Windows default value' listed before 'Linux default value' in the property table. However, there are no exclusive Windows or PowerShell examples, and all configuration examples use the cross-platform Azure CLI. There are no missing Linux examples, and no Windows-specific tools or patterns are promoted. The only other mention of Windows is a limitation note, which is relevant and not biased.
Recommendations:
  • List Linux and Windows defaults in parallel columns or in alphabetical order to avoid suggesting Windows as the primary platform.
  • Where platform-specific behaviors or settings exist, provide equal prominence and detail for both Windows and Linux.
  • Continue to use cross-platform tools (like Azure CLI) for configuration examples, and avoid introducing Windows-only tools unless Linux equivalents are also provided.
GitHub Create pull request

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