Azure Functions

385
Total Pages
248
Linux-Friendly Pages
137
Pages with Bias
35.6%
Bias Rate

Bias Trend Over Time

Pages with Bias Issues

1019 issues found
Showing 101-125 of 1019 flagged pages
Azure Functions Create your function app resources using Azure Resource Manager templates ...ns/functions-create-first-function-resource-manager.md
High Priority View Details →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
🔧 Windows Tools Powershell Heavy Windows First
Summary
The documentation provides both Azure CLI and Azure PowerShell examples for deploying ARM templates, but it includes extensive PowerShell instructions, which are primarily associated with Windows environments. The Azure PowerShell tab is presented as a first-class option alongside Azure CLI, and PowerShell is given equal coverage for all programming languages, including a dedicated 'programming-language-powershell' pivot. There is no mention of Linux-specific shell environments (e.g., Bash), nor are there examples using Bash scripts or Linux-native tools. The use of Azure Cloud Shell is referenced, which can run on both Windows and Linux, but the script examples are written in Azure CLI and PowerShell only. There is no explicit Linux bias, but the documentation leans towards Windows-centric tooling and scripting patterns.
Recommendations
  • Add Bash script examples for deploying ARM templates, especially for users on Linux or macOS.
  • Clarify that Azure CLI commands work cross-platform and can be run in Bash, Zsh, or other Linux shells.
  • Include notes or pivots for Linux/macOS users, highlighting any differences or prerequisites.
  • Reduce the emphasis on PowerShell by making Azure CLI the default or first example, as it is cross-platform.
  • Mention Linux-native tools (e.g., curl, jq) where relevant for template management or deployment.
  • Explicitly state that Azure Cloud Shell supports both Bash and PowerShell, and provide examples for both.
GitHub Create Pull Request
Azure Functions Develop and run Azure Functions locally ...in/articles/azure-functions/functions-develop-local.md
High Priority View Details →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Windows First 🔧 Windows Tools Powershell Heavy
Summary
The documentation page displays mild Windows bias. Visual Studio (Windows-only) is listed as the first and primary environment for C# development, with more detailed guidance and links than Linux/macOS alternatives. Windows-specific tools such as PowerShell are mentioned prominently in the HTTP test tools section, and the use of Visual Studio is emphasized for several languages. While Linux and macOS support is acknowledged (especially for Visual Studio Code and command-line tools), Windows-centric tools and workflows are often listed first or given more detail. There are no explicit Linux-only examples or tools highlighted, and PowerShell is referenced as a primary scripting/test tool, which is traditionally Windows-centric.
Recommendations
  • Ensure that Linux/macOS alternatives (such as JetBrains Rider, or native terminal instructions) are listed alongside or before Windows-only tools like Visual Studio for C# development.
  • Provide explicit Linux/macOS command-line examples and workflows, especially for common tasks such as running, debugging, and testing functions locally.
  • Highlight Linux-native HTTP test tools (e.g., httpie, wget) in addition to curl, and provide example usage.
  • Reduce emphasis on PowerShell as a default scripting/test tool; offer Bash/zsh equivalents for common commands.
  • Clarify when instructions or tools are Windows-only, and provide parity guidance for Linux/macOS users.
  • Consider adding a dedicated section for Linux/macOS development tips and troubleshooting.
GitHub Create Pull Request
Azure Functions Develop Azure Functions using Visual Studio .../main/articles/azure-functions/functions-develop-vs.md
High Priority View Details →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
Windows First Missing Linux Example 🔧 Windows Tools Powershell Heavy
Summary
The documentation is heavily focused on development using Visual Studio 2022, a Windows-centric IDE, and provides instructions and screenshots exclusively for Windows workflows. All examples, project setup, and debugging steps assume the use of Visual Studio on Windows, with no mention of Linux or cross-platform alternatives like VS Code. Package installation commands are shown only for PowerShell (Package Manager Console), and remote debugging is explicitly stated as only supported on Windows. There are no Linux-specific instructions, examples, or tool recommendations, and Windows tools and patterns are mentioned exclusively and first throughout.
Recommendations
  • Add equivalent instructions and examples for developing Azure Functions using VS Code or other cross-platform editors.
  • Include Linux-specific setup steps, screenshots, and troubleshooting tips.
  • Provide package installation examples using dotnet CLI (cross-platform) alongside PowerShell/Package Manager Console.
  • Clarify which steps and features are Windows-only and suggest Linux/macOS alternatives where possible.
  • Document remote debugging and deployment workflows for Linux-hosted function apps, or explicitly state limitations.
  • Reference Azure Functions Core Tools and Azure CLI usage for project creation, local development, and publishing, with examples for Linux/macOS.
  • Ensure parity in documentation structure and visibility for Linux and macOS users.
GitHub Create Pull Request
Azure Functions Continuously update function app code using Azure Pipelines ...icles/azure-functions/functions-how-to-azure-devops.md
High Priority View Details →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Windows First 🔧 Windows Tools Powershell Heavy
Summary
The documentation page demonstrates a moderate Windows bias. Windows-based examples and agent images ('windows-latest') are presented first for .NET and PowerShell, and the default deployment type is Windows. PowerShell is included as a first-class language, and Windows-specific instructions (such as deployment slots and agent pools) are often given before or more prominently than Linux equivalents. While Linux examples are present and parity is generally good for JavaScript, Python, and Java, the overall structure and defaults favor Windows environments.
Recommendations
  • Present Linux and Windows examples side-by-side or alternate which is shown first, especially for .NET and deployment sections.
  • Clarify when Windows or Linux is required for each language, and provide explicit guidance for cross-platform scenarios.
  • Add more context for PowerShell, noting its cross-platform capabilities, and include Bash or other shell examples where appropriate.
  • Highlight Linux as an equal default where possible, especially in introductory sections and YAML pipeline templates.
  • Ensure that all features (such as deployment slots and agent pools) are explained for both Windows and Linux, noting any limitations clearly.
GitHub Create Pull Request
Azure Functions Deployment technologies in Azure Functions ...s/azure-functions/functions-deployment-technologies.md
High Priority View Details →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
Windows First Missing Linux Example 🔧 Windows Tools Powershell Heavy
Summary
The documentation page demonstrates a Windows bias in several ways. Windows-based deployment methods (such as source control, local Git, and FTPS) are called out as 'Windows-only' in the technology availability table, while Linux equivalents are either limited or less emphasized. Examples and instructions often reference Visual Studio and Visual Studio Code (Windows-centric tools) before mentioning cross-platform or Linux-specific tools. The use of Kudu/scm site is described in detail for Windows, while Linux deployment options require additional manual configuration and are less straightforward. Some deployment methods (e.g., FTPS, Local Git) are unavailable or discouraged for Linux, and Linux-specific deployment patterns (such as containerization) are presented as niche or advanced scenarios. There are few explicit Linux command-line examples, and the documentation does not provide parity in step-by-step Linux deployment instructions.
Recommendations
  • Provide Linux-specific deployment examples and instructions alongside Windows examples, especially for common scenarios.
  • Ensure that cross-platform tools (such as Azure Functions Core Tools and Azure CLI) are highlighted before or equally with Windows-only tools like Visual Studio.
  • Clarify which deployment methods are available for Linux and provide guidance for Linux users, including troubleshooting and best practices.
  • Include explicit Linux shell command examples (bash/zsh) where appropriate, not just Azure CLI or PowerShell.
  • Expand documentation for Linux container deployments, making them more accessible and less 'advanced' or niche.
  • Where deployment methods are Windows-only, suggest Linux alternatives or workarounds, and explain the rationale for limitations.
  • Review the order of presentation so that Linux and cross-platform options are not always listed after Windows options.
GitHub Create Pull Request
Azure Functions Tutorial: Trigger Azure Functions on blob containers using an event subscription ...s/azure-functions/functions-event-grid-blob-trigger.md
High Priority View Details →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
🔧 Windows Tools Windows First Missing Linux Example
Summary
The documentation is heavily oriented around Visual Studio Code and its Azure extensions, which are available cross-platform but have a strong association with Windows workflows. All examples and instructions use VS Code GUI commands and extensions, with no mention of CLI alternatives (such as Azure CLI, PowerShell Core, Bash, or direct REST API usage) that are common on Linux. There are no explicit Linux-specific instructions or examples, and Windows-centric tools (like VS Code and Azurite extension) are referenced exclusively. The documentation does not provide parity for Linux users who may prefer command-line workflows or non-VS Code environments.
Recommendations
  • Add equivalent Azure CLI commands for all resource creation steps (storage account, blob container, function app, event subscription, file upload) alongside VS Code instructions.
  • Include PowerShell Core and Bash script examples for common tasks, ensuring they work on Linux and macOS as well as Windows.
  • Mention and provide instructions for using Azurite as a standalone npm package (not just the VS Code extension), which is the recommended approach on Linux.
  • Clarify that all steps can be performed on Linux and macOS, and explicitly call out any platform-specific limitations.
  • Provide links to official documentation for Azure CLI and REST API alternatives for users who do not use VS Code.
  • Add a section or callout for 'Linux/macOS users' with tips for setting up the environment and running the tutorial outside of VS Code.
GitHub Create Pull Request
Azure Functions host.json reference for Azure Functions 2.x ...b/main/articles/azure-functions/functions-host-json.md
High Priority View Details →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Powershell Heavy 🔧 Windows Tools Windows First
Summary
The documentation page exhibits mild Windows bias, primarily through its emphasis on PowerShell-based features (managedDependency is only supported for PowerShell), references to Windows-specific environment variables (e.g., %TEMP%), and use of Windows-centric terminology (e.g., 'local computer' rather than 'local machine' or 'local environment'). While most examples and instructions are platform-agnostic, Windows tools and conventions are mentioned before or instead of Linux equivalents, and Linux-specific guidance is minimal or relegated to notes.
Recommendations
  • Provide parity for managedDependency by clarifying support for other runtimes (e.g., Python, Node.js) or explicitly state limitations for non-Windows platforms.
  • When referencing environment variables (e.g., %TEMP%), include Linux equivalents (e.g., $TMPDIR, /tmp) and clarify platform-specific behavior.
  • In sections discussing local development, mention both Windows and Linux/Mac workflows, including relevant file paths and environment variables.
  • Expand documentation for console logging to include examples and troubleshooting for both Windows and Linux containers.
  • Review terminology to ensure cross-platform inclusivity (e.g., use 'local environment' instead of 'local computer').
  • Where PowerShell is referenced, provide equivalent Bash or shell script examples for Linux users, or clarify when features are Windows-only.
GitHub Create Pull Request
Azure Functions Configure function app settings in Azure Functions ...ns/functions-how-to-use-azure-function-app-settings.md
High Priority View Details →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
Windows First Powershell Heavy 🔧 Windows Tools Missing Linux Example
Summary
The documentation page demonstrates a notable Windows bias. Windows and PowerShell examples are consistently presented alongside Azure CLI and portal instructions, but Linux-specific guidance is sparse or missing. Windows tools and features (such as Kudu, App Service editor, and in-portal console) are highlighted, while Linux support is often marked as unavailable or limited. Migration and development scenarios are described primarily for Windows, with Linux options either omitted or described as unsupported. The documentation frequently presents Windows options first or exclusively, and Linux parity is not maintained throughout.
Recommendations
  • Provide explicit Linux examples and instructions for all CLI and portal operations, including any differences in command syntax, file paths, or prerequisites.
  • Clearly indicate feature parity and limitations for Linux users, and offer alternative workflows or tools where Windows-only features are unavailable.
  • Include Linux-specific troubleshooting and best practices, especially for deployment, extension installation, and local development.
  • Where PowerShell is presented, offer equivalent Bash or shell scripting examples for Linux users.
  • Reorganize sections to avoid presenting Windows tools and workflows first or exclusively; ensure equal prominence for Linux scenarios.
  • Update tables and feature matrices to clarify Linux support and suggest alternatives for missing features.
  • Add guidance for Linux plan migration, or explicitly state if/when such scenarios are not supported, and link to relevant roadmap or support documentation.
GitHub Create Pull Request
Azure Functions Automate function app resource deployment to Azure ...es/azure-functions/functions-infrastructure-as-code.md
High Priority View Details →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Windows First 🔧 Windows Tools Powershell Heavy
Summary
The documentation provides both Windows and Linux examples for most deployment scenarios, but consistently presents Windows examples before Linux equivalents, especially in code samples and configuration tables. PowerShell is the only scripting language shown for deployment automation, and Windows-specific tools and settings (such as Visual Studio Code extensions and portal workflows) are mentioned before or instead of Linux alternatives. There are no Bash or Linux shell deployment examples, and some references (such as the 'Deploy to Azure' button example) link to Windows-focused templates. The documentation does not mention Linux-native tools (e.g., Bash, shell scripts) for deployment or validation.
Recommendations
  • Present Linux examples before or alongside Windows examples in all code and configuration sections.
  • Include Bash/Azure CLI shell script examples for deployment and validation, not just PowerShell.
  • Reference Linux-native tools (such as Vim, VS Code on Linux, or other editors) for template authoring and validation.
  • Ensure that links to sample templates and quickstarts include Linux-focused scenarios and are not Windows-only.
  • Clarify in deployment instructions that all steps can be performed on Linux, and provide explicit guidance for Linux users.
  • Add notes or sections on differences in deployment experience between Windows and Linux, especially for CI/CD and automation.
GitHub Create Pull Request
Azure Functions Monitor executions in Azure Functions .../main/articles/azure-functions/functions-monitoring.md
High Priority View Details →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Windows First Missing Linux Example 🔧 Windows Tools
Summary
The documentation page demonstrates a Windows bias by prioritizing Windows features and tools, such as Performance Counters and built-in log streaming, which are either unsupported or limited on Linux. Linux limitations are mentioned only as caveats, and there are no Linux-specific examples or alternative workflows provided. The documentation does not offer parity in guidance for Linux users, especially regarding performance monitoring and log streaming.
Recommendations
  • Provide Linux-specific examples and workflows for monitoring and log streaming, including recommended tools and commands.
  • Clearly document alternative approaches for Linux users where Windows features (e.g., Performance Counters, built-in log streaming) are unavailable.
  • Add guidance on using cross-platform or Linux-native monitoring tools (such as Prometheus, Grafana, or native Linux metrics) alongside Application Insights.
  • Ensure that limitations for Linux are not just mentioned as caveats, but are accompanied by actionable alternatives.
  • Include parity in troubleshooting and diagnostic instructions for both Windows and Linux environments.
GitHub Create Pull Request
Azure Functions Azure Functions networking options ...ticles/azure-functions/functions-networking-options.md
High Priority View Details →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
Windows First Powershell Heavy Missing Linux Example 🔧 Windows Tools
Summary
The documentation exhibits several signs of Windows bias. Hybrid Connections are explicitly stated as only supported for Windows, with Linux apps not supported. In automation and configuration examples, Azure PowerShell is presented alongside Azure CLI, but PowerShell is a Windows-centric tool. The subnet sizing recommendations mention Windows before Linux, and the minimum required subnet size for Windows is described first. There are no Linux-specific configuration or troubleshooting examples, and the documentation does not provide parity for Linux users in features or guidance, especially regarding Hybrid Connections and automation.
Recommendations
  • Provide explicit Linux support status and alternatives for features like Hybrid Connections, or clarify if/when Linux support is planned.
  • Offer Linux-specific examples and troubleshooting steps, especially for automation (e.g., bash scripts, Azure CLI only workflows).
  • Present Azure CLI examples before PowerShell, as CLI is cross-platform.
  • When listing subnet sizing recommendations, present Linux and Windows requirements together or alternate the order.
  • Clearly indicate any feature limitations for Linux and suggest workarounds or equivalent Linux-compatible solutions.
  • Add notes or links to Linux documentation where relevant, ensuring Linux users can easily find guidance.
GitHub Create Pull Request
Azure Functions Develop Azure Functions locally using Core Tools ...b/main/articles/azure-functions/functions-run-local.md
High Priority View Details →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Windows First 🔧 Windows Tools Powershell Heavy
Summary
The documentation generally aims for cross-platform parity, but there are subtle biases toward Windows. Windows command-line examples are provided alongside Bash, and Windows-specific tools (PowerShell, MSI installers) are mentioned without always giving equal prominence to Linux alternatives. The documentation references 'command prompt' and 'func.exe' (a Windows-specific executable name) and sometimes lists Windows tools before Linux equivalents. PowerShell is treated as a first-class language, which may not reflect its usage on Linux.
Recommendations
  • When providing command-line examples, always include both Bash (Linux/macOS) and Windows (cmd/PowerShell) versions, and clearly label them.
  • Avoid using Windows-specific terminology like 'command prompt' or 'func.exe' in generic sections; use 'terminal' and 'func' instead.
  • When referencing tools for authentication or deployment (e.g., Azure CLI, Azure PowerShell), ensure Linux installation and usage instructions are equally prominent.
  • If PowerShell is mentioned as a language or scripting environment, clarify its cross-platform availability and provide Bash alternatives where appropriate.
  • In sections discussing installation or upgrades, provide explicit instructions for Linux (e.g., apt, yum, npm) alongside Windows (MSI) methods.
  • Ensure that any references to file paths, environment variables, or configuration files use cross-platform conventions or provide both Windows and Linux/macOS examples.
GitHub Create Pull Request
Azure Functions Azure Functions Premium plan ...ain/articles/azure-functions/functions-premium-plan.md
High Priority View Details →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
Windows First Powershell Heavy Missing Linux Example 🔧 Windows Tools
Summary
The documentation page demonstrates a Windows bias in several ways: Windows and PowerShell examples are consistently provided alongside Azure CLI, but Linux-specific examples or shell scripts are absent. The migration section explicitly states that migration between plans is only supported on Windows, with no Linux alternative or workaround. Throughout, Windows terminology and tools (such as PowerShell) are mentioned at least as prominently as cross-platform options, and sometimes exclusively (e.g., migration commands). There is little to no guidance for Linux users beyond mentioning Linux container support and listing Linux scale-out limits.
Recommendations
  • Provide explicit Linux shell (bash) examples for all CLI commands, including environment variable usage and scripting patterns common on Linux.
  • Where PowerShell is referenced, add equivalent bash or shell script examples, or clarify that Azure CLI commands are cross-platform.
  • In migration guidance, clarify Linux limitations and suggest workarounds or alternative approaches for Linux users.
  • Add troubleshooting and configuration notes specific to Linux environments, such as file permissions, container nuances, or OS-specific behaviors.
  • Ensure that Windows and Linux parity is maintained in all code samples and instructions, and avoid presenting Windows-first or Windows-only workflows unless strictly necessary.
GitHub Create Pull Request
Azure Functions Guidance for developing Azure Functions ...b/main/articles/azure-functions/functions-reference.md
High Priority View Details →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Windows First 🔧 Windows Tools Powershell Heavy
Summary
The documentation page demonstrates a moderate Windows bias. Windows-centric tools such as Visual Studio and PowerShell are mentioned explicitly and often appear before cross-platform or Linux-native alternatives. Visual Studio (Windows-only) is listed as the primary IDE for C#, and PowerShell is included as a first-class language option. There is little explicit mention of Linux-specific workflows, editors, or shell environments (e.g., Bash), and no Linux-specific examples or tool recommendations are provided. The use of 'command prompt' is ambiguous and could be interpreted as Windows Command Prompt, furthering the Windows-first impression.
Recommendations
  • Explicitly mention Linux and macOS compatibility for all tools, especially Azure Functions Core Tools and Visual Studio Code.
  • Provide Linux-specific quickstart and deployment examples, including usage of Bash and common Linux package managers (apt, yum, etc.).
  • Clarify 'command prompt' references by specifying cross-platform shells (e.g., Bash, zsh, PowerShell Core) and provide examples for each.
  • Include Linux-native editors (e.g., Vim, Emacs) in tool recommendations where appropriate.
  • Ensure parity in language-specific guides by referencing Linux/Mac workflows and troubleshooting steps.
  • Add notes or sections highlighting differences or considerations when developing and deploying Azure Functions from Linux environments.
GitHub Create Pull Request
Azure Functions Azure Functions Scale and Hosting .../blob/main/articles/azure-functions/functions-scale.md
High Priority View Details →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Windows First 🔧 Windows Tools Missing Linux Example
Summary
The documentation page demonstrates a Windows bias in several ways. Windows-based hosting options (Consumption plan) are described first and in more detail, with explicit mention of Windows dependencies such as PowerShell modules and the full .NET Framework. Linux options are often described as secondary, with Linux Consumption retired and Linux container support discussed as an advanced or niche feature. There are no Linux-specific tooling or deployment examples, and Windows terminology (App Service, .NET Framework, PowerShell) is used without Linux equivalents. The documentation lacks parity in examples and guidance for Linux users, especially those using Linux-native tools or workflows.
Recommendations
  • Provide Linux-specific examples and guidance, such as deployment using Bash, CLI, or Linux-native tools.
  • Mention Linux hosting options and features before or alongside Windows options, especially where Linux is the default or recommended platform.
  • Include references to Linux equivalents for Windows-specific features (e.g., PowerShell modules vs. Bash scripts, .NET Framework vs. .NET Core).
  • Clarify container support for both platforms and highlight Linux container workflows with practical examples.
  • Add troubleshooting and migration guidance for Linux users, especially regarding the retirement of Linux Consumption plan.
  • Balance terminology and feature descriptions to avoid implying Windows is the default or preferred platform.
GitHub Create Pull Request
Azure Functions Create a function in Azure from the command line ...es/azure-functions/how-to-create-function-azure-cli.md
High Priority View Details →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
Windows First Powershell Heavy 🔧 Windows Tools Missing Linux Example
Summary
The documentation page demonstrates some Windows bias. Examples for creating and running Azure Functions projects are often presented with Windows-centric tools and patterns. PowerShell and CMD examples are provided alongside Bash, but Bash is not always presented first. The Maven archetype flow for Java includes explicit tabs for PowerShell and CMD, which are Windows-specific, while Bash is just one of several options. There is mention of setting JAVA_HOME, which is relevant for both platforms, but the file path example uses backslashes (\src\main\java\com\fabrikam), a Windows convention. There are no explicit Linux-specific troubleshooting notes, nor are Linux shell patterns (e.g., shebangs, environment variable export) shown. The use of 'terminal or command prompt' is ambiguous and could be clarified for cross-platform parity. The documentation does not provide explicit Linux-only examples or highlight differences for Linux users, and Windows tools/patterns (PowerShell, CMD, backslashes) are often presented before or alongside Bash.
Recommendations
  • Present Bash examples before PowerShell and CMD in all code tabs, or default to Bash where possible.
  • Use forward slashes in file path examples, or clarify that both Windows and Linux paths are supported.
  • Explicitly mention Linux/macOS terminals in instructions, not just 'command prompt'.
  • Add troubleshooting notes for Linux users, such as permissions, environment variable export, and package installation.
  • Ensure all CLI commands are tested and shown in Bash, and clarify any differences for PowerShell/CMD.
  • Avoid Windows-centric terminology and patterns unless necessary, and provide Linux/macOS equivalents where appropriate.
GitHub Create Pull Request
Azure Functions Create and deploy function code to Azure using Visual Studio Code ...cles/azure-functions/how-to-create-function-vs-code.md
High Priority View Details →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
🔧 Windows Tools Windows First Powershell Heavy
Summary
The documentation demonstrates mild Windows bias, primarily through the use of Windows-specific tools, terminology, and ordering. PowerShell is included as a first-class language option, and some instructions and troubleshooting steps reference Windows-specific behaviors (e.g., default terminal shell issues with WSL Bash). In cross-platform build instructions for Go and Rust, Windows steps are presented after macOS/Linux, but Windows-specific details (such as changing 'handler.exe' to 'handler') are called out. The PowerShell prerequisites link only to Windows installation instructions, and the troubleshooting section includes a Windows-specific note about terminal shells.
Recommendations
  • Ensure all language and tool prerequisites include explicit instructions for Linux and macOS, not just Windows (e.g., PowerShell installation links for Linux/macOS).
  • When referencing platform-specific issues (e.g., default terminal shell), provide equivalent troubleshooting for Linux/macOS users.
  • In build instructions, present all platforms equally and clarify any platform-specific steps, rather than focusing on Windows-specific file extensions or behaviors.
  • Include examples and notes for Linux/macOS users wherever Windows-specific tools or patterns are mentioned.
  • Review and update links to ensure parity in guidance for all supported platforms, especially for language runtimes and extensions.
GitHub Create Pull Request
Azure Functions Azure Functions language stack support policy ...in/articles/azure-functions/language-support-policy.md
High Priority View Details →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Powershell Heavy 🔧 Windows Tools Windows First
Summary
The documentation page demonstrates mild Windows bias. PowerShell is included as a primary supported language and is given its own resource section. In the FAQ, PowerShell is listed as one of the main ways to check runtime versions, alongside Azure Portal and Azure CLI, with no mention of Linux-native tools or shell commands. There is no explicit Linux example or parity for checking runtime versions, and Windows-centric tooling (PowerShell) is presented as a standard option.
Recommendations
  • Include Linux-native command examples (e.g., Bash, curl, or REST API usage) for common tasks such as checking runtime versions.
  • Clarify that Azure CLI is cross-platform and provide explicit Linux usage instructions or examples.
  • Add references to Linux tools or shell commands where PowerShell is mentioned, ensuring equal visibility.
  • Consider adding a section or FAQ entry addressing Linux-specific considerations for Azure Functions development and management.
GitHub Create Pull Request
Azure Functions Deploy a PyTorch model as an Azure Functions application ...n/articles/azure-functions/machine-learning-pytorch.md
High Priority View Details →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
Windows First Powershell Heavy 🔧 Windows Tools Missing Linux Example
Summary
The documentation provides examples for bash, PowerShell, and Cmd, but Windows-specific tools and patterns (such as 'py' launcher, PowerShell, registry edits, and Visual Studio Code) are mentioned frequently and sometimes before their Linux equivalents. Troubleshooting tips and error messages focus on Windows issues (e.g., long path registry edits), while Linux-specific troubleshooting is minimal. The use of 'py' launcher and PowerShell commands may confuse Linux users, and Visual Studio Code is promoted as the primary editor without mentioning Linux alternatives. Some sections (e.g., error handling, editor recommendations) lack Linux-specific guidance.
Recommendations
  • Ensure Linux and macOS examples are presented before or alongside Windows examples, not after.
  • Provide troubleshooting tips for common Linux/macOS issues (e.g., permissions, missing dependencies) in addition to Windows-specific errors.
  • Mention Linux-friendly editors (e.g., Vim, Emacs, GNOME Builder) alongside Visual Studio Code.
  • Clarify command differences: explicitly state when 'py' is Windows-only and recommend 'python' for Linux/macOS.
  • Include Linux/macOS-specific instructions for enabling long paths or handling deep directory structures.
  • Balance PowerShell/Cmd examples with bash/zsh/fish shell examples, and avoid assuming PowerShell is available on all platforms.
  • Add a section summarizing cross-platform differences and how to adapt commands for each OS.
GitHub Create Pull Request
Azure Functions Migrate apps from Azure Functions version 3.x to 4.x ...rticles/azure-functions/migrate-version-3-version-4.md
High Priority View Details →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Powershell Heavy Windows First Missing Linux Example
Summary
The documentation page demonstrates Windows bias primarily by providing only PowerShell scripts for identifying apps to migrate, referencing Azure PowerShell as the default tool, and omitting equivalent Linux/bash/CLI examples. The initial migration steps and tooling recommendations (such as Visual Studio and .NET Upgrade Assistant) are Windows-centric, with Linux alternatives not mentioned or deferred. While the content is technically cross-platform, the presentation and examples favor Windows users.
Recommendations
  • Provide Azure CLI/bash equivalents for all PowerShell scripts, especially for identifying function apps to migrate.
  • Mention and demonstrate cross-platform tools (such as VS Code, Azure CLI, and Functions Core Tools) alongside Windows-specific tools like Visual Studio.
  • Ensure that migration instructions and examples are available for Linux/macOS environments, including shell commands and tool installation steps.
  • Explicitly state platform compatibility for all tools and scripts, and link to Linux/macOS documentation where relevant.
  • Reorder examples so that cross-platform or Linux options are presented alongside or before Windows-specific instructions.
GitHub Create Pull Request
Azure Functions Migrate C# app from in-process to isolated worker model ...es/azure-functions/migrate-dotnet-to-isolated-model.md
High Priority View Details →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
Powershell Heavy 🔧 Windows Tools Missing Linux Example Windows First
Summary
The documentation page demonstrates a bias toward Windows environments by exclusively providing Azure PowerShell scripts for identifying function apps, referencing Visual Studio (a Windows-centric IDE) for deployment, and omitting equivalent Linux/macOS CLI examples (such as Bash, Azure CLI, or cross-platform editors like VS Code). Windows tools and workflows are mentioned first and sometimes exclusively, with no guidance for Linux users on how to perform the same tasks.
Recommendations
  • Provide equivalent Azure CLI (az) and/or Bash script examples for identifying function apps and managing subscriptions, alongside the PowerShell example.
  • Include instructions for deploying and managing Azure Functions using VS Code and/or command-line tools that are cross-platform, not just Visual Studio.
  • Explicitly mention Linux/macOS compatibility and provide steps for those platforms where workflows differ (e.g., setting environment variables, publishing from non-Windows environments).
  • Add notes or tabs for Linux/macOS users in sections that currently only describe Windows/PowerShell/Visual Studio workflows.
  • Ensure that all tooling and configuration steps (such as updating settings, publishing, and slot swaps) are described in a platform-neutral way, or with clear alternatives for Linux/macOS.
GitHub Create Pull Request
Azure Functions Migrate apps from Azure Functions version 1.x to 4.x ...rticles/azure-functions/migrate-version-1-version-4.md
High Priority View Details →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Powershell Heavy 🔧 Windows Tools Windows First
Summary
The documentation page exhibits a Windows bias primarily through its reliance on PowerShell scripts for identifying function apps to migrate, with no equivalent Bash, Azure CLI, or Linux-native instructions provided. Windows tools and workflows (such as Visual Studio publishing and PowerShell scripting) are referenced exclusively or before any Linux alternatives. This may hinder Linux users or those who prefer cross-platform tooling from following the migration process smoothly.
Recommendations
  • Provide Azure CLI and/or Bash script equivalents for all PowerShell examples, especially for identifying function apps to migrate.
  • Explicitly mention cross-platform tools and workflows (such as VS Code, Azure CLI, or GitHub Actions) alongside Windows-specific tools like Visual Studio.
  • Ensure that instructions for setting the active subscription and other environment setup steps are available for both Windows and Linux shells.
  • Add notes or sections clarifying which steps are platform-agnostic and which require adaptation for Linux/macOS environments.
  • Consider reordering examples so that cross-platform or Linux-native instructions are presented before or alongside Windows/PowerShell examples.
GitHub Create Pull Request
Azure Functions Migrate Consumption plan apps to Flex Consumption in Azure Functions ...unctions/migration/migrate-plan-consumption-to-flex.md
High Priority View Details →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
Windows First Powershell Heavy 🔧 Windows Tools Missing Linux Example
Summary
The documentation provides migration steps for both Linux and Windows Azure Functions apps, but there is a noticeable Windows bias. Windows-specific tools, commands, and patterns (such as Azure CLI commands, Kusto queries, and portal navigation) are often presented first or in greater detail. Many examples and scripts are tailored for Windows environments, with Linux equivalents sometimes missing, less detailed, or referenced as secondary. The documentation frequently assumes familiarity with Windows conventions and tools, and the migration process for Linux is less automated and less thoroughly documented compared to Windows. The use of PowerShell and Windows-centric Azure CLI commands is prevalent, while Linux-specific instructions are sometimes less emphasized or omitted.
Recommendations
  • Ensure Linux examples are provided for every Windows example, with equal detail and clarity.
  • Present Linux and Windows instructions side-by-side, or alternate which platform is presented first.
  • Include Linux-native tools and patterns (e.g., bash scripts, Linux file system paths, Linux-specific troubleshooting steps) where appropriate.
  • Avoid assuming Windows conventions (such as PowerShell, Windows file shares, or portal navigation) are the default; clarify when instructions are platform-specific.
  • Expand the use of automated migration tools for Linux, and document their usage as thoroughly as for Windows.
  • Review and update portal screenshots and navigation instructions to reflect both Linux and Windows experiences.
  • Solicit feedback from Linux users to identify gaps in parity and usability.
GitHub Create Pull Request
Azure Functions Troubleshoot Python function apps in Azure Functions ...n/articles/azure-functions/recover-python-functions.md
High Priority View Details →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
Windows First Powershell Heavy 🔧 Windows Tools Missing Linux Example
Summary
The documentation exhibits some Windows bias, including presenting Windows/PowerShell commands before their Linux equivalents, referencing Windows-specific tools and patterns, and occasionally omitting equivalent Linux guidance or examples. While Linux is acknowledged as the Azure Functions runtime environment, troubleshooting and local development instructions often prioritize or assume Windows usage, and some sections lack parity in detail or examples for Linux users.
Recommendations
  • Ensure command examples are presented for both Windows and Linux/Unix shells, ideally side-by-side or with equal prominence.
  • Avoid listing Windows/PowerShell commands before Linux equivalents; use tabs or pivots to let users select their OS.
  • Include explicit instructions for Linux environments wherever Windows tools or patterns are mentioned (e.g., Visual Studio Code, Core Tools, file paths, environment variables).
  • Highlight Linux-specific troubleshooting steps and common issues, especially since Azure Functions runs on Linux.
  • Review all examples and ensure Linux users are not required to infer steps from Windows-centric instructions.
  • Where Windows-only packages (e.g., pywin32) are discussed, provide guidance for Linux alternatives or workarounds.
  • Clarify when instructions or tools are OS-agnostic and when they are not, to avoid confusion for non-Windows users.
GitHub Create Pull Request
Azure Functions Build a custom remote MCP server using Azure Functions ...s/azure-functions/scenario-custom-remote-mcp-server.md
High Priority View Details →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
🔧 Windows Tools Windows First Powershell Heavy
Summary
The documentation page demonstrates some Windows bias, particularly in the deployment and connection steps. Windows/PowerShell instructions are provided in detail and are presented before Linux/macOS equivalents in the 'Connect to your remote MCP server' section. The use of PowerShell and Windows-specific scripting is prominent, while Linux/macOS instructions are present but less detailed. There is also a reliance on Visual Studio Code, which, while cross-platform, is often associated with Windows workflows. No explicit Linux-only tools or shell examples are given outside the basic Bash script, and there is no mention of alternative Linux editors or terminal environments.
Recommendations
  • Ensure Linux/macOS instructions are as detailed and prominent as Windows/PowerShell examples.
  • Provide examples using common Linux shells (e.g., Bash, Zsh) and clarify any differences in environment variable handling.
  • Mention and support alternative editors or terminal environments commonly used on Linux (e.g., Vim, GNOME Terminal, etc.) where relevant.
  • Avoid presenting Windows/PowerShell instructions before Linux/macOS equivalents; consider parallel presentation or defaulting to cross-platform CLI commands.
  • Explicitly state cross-platform compatibility for tools and commands, and provide troubleshooting tips for Linux users if needed.
GitHub Create Pull Request
← Previous Page 5 of 41 Next →