Azure Functions

711
Total Pages
610
Linux-Friendly Pages
101
Pages with Bias
14.2%
Bias Rate

Bias Trend Over Time

Pages with Bias Issues

233 issues found
Showing 151-175 of 233 flagged pages
Azure Functions host.json reference for Azure Functions 2.x ...b/main/articles/azure-functions/functions-host-json.md
Low Priority View Details →
Scanned: 2026-01-24 00:00
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Powershell Heavy 🔧 Windows Tools Windows Terms
Summary
The documentation is generally cross-platform and does not show strong Windows bias. However, there are some minor Windows-centric elements: the managedDependency feature is described as PowerShell-only (which is most commonly used on Windows), and some references to environment variables use Windows-style syntax (e.g., %TEMP%). There are also mentions of Windows-specific folders in fallback logic for snapshot debugging. No critical configuration steps or examples are Windows-only, and Linux/macOS users can follow all instructions.
Recommendations
  • Clarify when environment variable references (e.g., %TEMP%) are platform-specific, and provide Linux/macOS equivalents (e.g., $TMPDIR or /tmp).
  • Where fallback folder logic is described, mention how it works on Linux/macOS.
  • For managedDependency, explicitly state that PowerShell functions are supported on both Windows and Linux, if true, or clarify platform limitations.
  • Ensure that any references to file paths or folders are accompanied by notes about platform differences.
GitHub Create Pull Request
Azure Functions App settings reference for Azure Functions ...ain/articles/azure-functions/functions-app-settings.md
Low Priority View Details →
Scanned: 2026-01-23 00:00
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Windows First 🔧 Windows Tools Powershell Heavy
Summary
The documentation is generally cross-platform and covers both Windows and Linux scenarios for Azure Functions app settings. However, there are some instances of Windows bias: Windows-specific syntax (e.g., %HOME% in AzureWebJobs_TypeScriptPath) is shown without Linux equivalents; PowerShell-specific settings are documented in detail, while other language runtimes (e.g., bash, sh) are not mentioned; and Windows-only settings (e.g., WEBSITE_NODE_DEFAULT_VERSION) are called out, but Linux equivalents are not always shown first or equally. Some examples and patterns (such as hierarchical delimiters) explain Windows behavior before Linux. The use of Azure CLI and Azure PowerShell is recommended for managing settings, but Linux-native tools (e.g., bash, curl) are not suggested.
Recommendations
  • For settings where Windows syntax is shown (e.g., %HOME%), add equivalent Linux/macOS examples (e.g., $HOME).
  • When documenting PowerShell-specific settings, provide parity by mentioning if similar settings exist for bash/sh or other Linux-native runtimes.
  • When recommending tools for managing app settings, include Linux-native options (e.g., Azure CLI usage from bash, REST API with curl) alongside Azure PowerShell.
  • In sections discussing reserved delimiters (double-underscore vs colon), present Linux behavior first or equally, and clarify differences up front.
  • For settings that are OS-specific (e.g., WEBSITE_NODE_DEFAULT_VERSION), always indicate Linux alternatives or explicitly state if none exist.
GitHub Create Pull Request
Azure Functions Guide for running C# Azure Functions in an isolated worker process ...icles/azure-functions/dotnet-isolated-process-guide.md
Low Priority View Details →
Scanned: 2026-01-23 00:00
Reviewed by: LLM Analysis
Issues: 2 bias types
Detected Bias Types
Windows First 🔧 Windows Tools
Summary
The documentation is largely cross-platform and provides both Windows and Linux guidance for running C# Azure Functions in the isolated worker process. However, there are a few areas where Windows tools or patterns are mentioned before Linux equivalents, and some CLI examples default to Windows-first (e.g., checking 32/64-bit status, ReadyToRun instructions). Azure PowerShell is listed as a deployment option alongside Azure CLI, but not all Linux users will have PowerShell installed. Overall, Linux parity is strong, but minor ordering and tool preference biases exist.
Recommendations
  • When listing deployment or resource creation methods, mention Azure CLI before Azure PowerShell, as CLI is more universally available across platforms.
  • In tables or lists that show both Windows and Linux instructions, alternate the order or clarify that both are equally supported.
  • Where CLI commands are shown for Windows, ensure Linux equivalents are shown immediately after or in parallel.
  • If referencing Visual Studio, always mention Visual Studio Code as an alternative for Linux/macOS users in the same context.
  • Explicitly state in the introduction that all features (unless noted) are supported on both Windows and Linux, to reassure non-Windows users.
GitHub Create Pull Request
Azure Functions Storage considerations for Azure Functions ...ain/articles/azure-functions/storage-considerations.md
Low Priority View Details →
Scanned: 2026-01-23 00:00
Reviewed by: LLM Analysis
Issues: 2 bias types
Detected Bias Types
Windows First Powershell Heavy
Summary
The documentation is generally cross-platform and covers both Windows and Linux hosting scenarios for Azure Functions. However, there are minor signs of Windows bias: in the 'Mount file shares' section, PowerShell examples are presented alongside Azure CLI, and references to Windows hosting plans (e.g., Consumption plan on Windows) appear before Linux equivalents in some places. The majority of examples and guidance are platform-neutral, and Linux-specific features (like mounting Azure Files shares) are clearly documented. There are no critical omissions for Linux users.
Recommendations
  • Ensure that Linux examples (CLI, code snippets) are presented before or alongside Windows/PowerShell examples, especially in sections relevant to both platforms.
  • Where PowerShell is shown, consider also providing Bash or Linux shell equivalents if applicable.
  • Explicitly clarify platform applicability in each example or section to help users quickly identify relevant instructions.
  • Continue to expand Linux-specific guidance, especially for advanced deployment and storage scenarios.
GitHub Create Pull Request
Azure Functions Event-driven Scaling in Azure Functions .../main/articles/azure-functions/event-driven-scaling.md
Low Priority View Details →
Scanned: 2026-01-22 00:00
Reviewed by: LLM Analysis
Issues: 2 bias types
Detected Bias Types
Windows First Powershell Heavy
Summary
The documentation provides both Azure CLI and PowerShell examples for configuring scale limits, but PowerShell is presented as a primary tab alongside CLI, and there are no explicit Linux/macOS shell examples (e.g., Bash, zsh). The only OS-specific note is about Windows Consumption plan apps and drain mode, but this is a factual distinction, not a bias. Overall, the examples and instructions are cross-platform, but the prominence of PowerShell and lack of explicit Linux/macOS shell commands may create minor friction for non-Windows users.
Recommendations
  • Add explicit Bash or shell examples for configuration tasks, especially where PowerShell is shown.
  • Clarify that Azure CLI commands work on Linux/macOS and Windows equally.
  • Where PowerShell is presented, consider adding a note or alternative for Linux/macOS users who may not use PowerShell.
  • Ensure that any OS-specific behaviors (like drain mode for Windows Consumption plan apps) are clearly marked as such and alternatives or clarifications for Linux/macOS are provided if relevant.
GitHub Create Pull Request
Azure Functions App settings reference for Azure Functions ...ain/articles/azure-functions/functions-app-settings.md
Low Priority View Details →
Scanned: 2026-01-22 00:00
Reviewed by: LLM Analysis
Issues: 2 bias types
Detected Bias Types
Windows First 🔧 Windows Tools
Summary
The documentation is generally cross-platform and covers both Windows and Linux scenarios for Azure Functions app settings. However, there are minor instances of Windows bias: some examples use Windows-style paths (e.g., %HOME%\typescript), and in a few cases, Windows-specific settings (like WEBSITE_NODE_DEFAULT_VERSION) are presented before Linux equivalents or without Linux alternatives. Additionally, references to using Azure CLI or Azure PowerShell for managing settings may implicitly favor Windows users, though CLI is cross-platform.
Recommendations
  • Where paths or environment variables are shown, provide both Windows and Linux/macOS examples (e.g., %HOME%\typescript and $HOME/typescript).
  • When mentioning tools for managing settings (Azure CLI, PowerShell), clarify that Azure CLI is cross-platform and provide Bash or shell examples where appropriate.
  • For settings that are OS-specific (e.g., WEBSITE_NODE_DEFAULT_VERSION), explicitly state their applicability and, where possible, provide Linux/macOS equivalents or alternatives.
  • Ensure that examples and explanations do not default to Windows conventions unless the setting is Windows-only.
GitHub Create Pull Request
Azure Functions Use Python and TensorFlow for machine learning in Azure ...ure-functions/functions-machine-learning-tensorflow.md
Low Priority View Details →
Scanned: 2026-01-22 00:00
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Windows First Powershell Heavy 🔧 Windows Tools
Summary
The documentation provides platform-specific instructions for creating and activating Python virtual environments, copying files, and running HTTP servers, with examples for Bash (Linux/macOS), PowerShell, and Cmd (Windows). However, Windows examples (PowerShell and Cmd) are consistently listed after Bash, and Windows-specific tools (such as 'py' launcher and registry edits) are mentioned. There is a notable Windows troubleshooting section for long path issues, but Linux/macOS equivalents are not discussed. The documentation does include Bash examples and notes for Linux users, but Windows-specific instructions and troubleshooting are more detailed.
Recommendations
  • Ensure troubleshooting sections include Linux/macOS equivalents where relevant (e.g., file path issues, permissions).
  • Balance troubleshooting advice for Windows and Linux/macOS users.
  • Where Windows-specific tools (like 'py' launcher) are mentioned, clarify Linux/macOS alternatives (e.g., always use 'python3').
  • Consider listing Bash (Linux/macOS) and Windows examples in alternating order, or clarify that all platforms are equally supported.
  • Add notes about common Linux/macOS issues (e.g., permissions, package installation errors) where Windows-specific issues are discussed.
GitHub Create Pull Request
Azure Functions Memory profiling of Python apps in Azure Functions ...es/azure-functions/python-memory-profiler-reference.md
Low Priority View Details →
Scanned: 2026-01-22 00:00
Reviewed by: LLM Analysis
Issues: 1 bias type
Detected Bias Types
Windows First
Summary
The documentation generally provides cross-platform instructions and examples, but in the 'Profile Python function app in local development environment' section, Windows commands and terminology are presented before Linux equivalents (e.g., 'py -m venv .venv' for Windows is listed before 'python3 -m venv .venv' for Linux, and PowerShell activation before Linux shell). This is a minor ordering bias, but Linux users are not blocked and all necessary Linux commands are present.
Recommendations
  • Present Linux and Windows commands in parallel tabbed sections or side-by-side for parity.
  • When listing commands for both platforms, alternate which platform is shown first, or clarify that both are equally supported.
  • Explicitly mention macOS where relevant (e.g., 'Linux/macOS shell') to cover all non-Windows users.
  • Consider using tabbed code blocks for 'Windows', 'Linux', and 'macOS' where commands differ.
GitHub Create Pull Request
Azure Functions Guide for running C# Azure Functions in an isolated worker process ...icles/azure-functions/dotnet-isolated-process-guide.md
Low Priority View Details →
Scanned: 2026-01-16 00:00
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Windows First 🔧 Windows Tools Powershell Heavy
Summary
The documentation is generally cross-platform and covers both Windows and Linux scenarios for running C# Azure Functions in the isolated worker process. However, there are several instances where Windows tools and patterns are mentioned first or in more detail, and some CLI examples use Windows-centric language. Azure PowerShell is listed as a resource creation method alongside Azure CLI, but Linux shell examples are not always shown with equal prominence. Some instructions (e.g., for checking or setting 32/64-bit process, ReadyToRun, and preview SDK usage) show Windows commands or options first, with Linux as a secondary tab or note.
Recommendations
  • Wherever CLI commands are shown, ensure both Windows (PowerShell/CMD) and Linux (Bash) equivalents are provided, or use cross-platform Azure CLI examples by default.
  • When listing resource creation or deployment methods, present Azure CLI and Visual Studio Code before Windows-specific tools like Visual Studio or Azure PowerShell.
  • In tables or lists, alternate the order of Windows and Linux to avoid always presenting Windows first.
  • Add explicit Linux/macOS shell examples for common tasks (e.g., checking process architecture, publishing with dotnet CLI) where only Windows or PowerShell is shown.
  • Clarify when a tool or step is Windows-only, and provide Linux/macOS alternatives where possible.
GitHub Create Pull Request
Azure Functions Guide for running C# Azure Functions in an isolated worker process ...icles/azure-functions/dotnet-isolated-process-guide.md
Low Priority View Details →
Scanned: 2026-01-15 00:00
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Windows First 🔧 Windows Tools Powershell Heavy
Summary
The documentation generally presents a cross-platform approach, but there are several areas where Windows tools and patterns are mentioned before or more prominently than Linux equivalents. Windows-specific configuration steps and CLI commands are often shown first, and Azure PowerShell is listed as a primary resource creation method, while Bash or Linux shell examples are not always equally highlighted. Some sections (e.g., ReadyToRun, deployment, and preview SDK configuration) provide Windows instructions first or in more detail, and PowerShell is referenced as a main automation tool.
Recommendations
  • Ensure that Linux and macOS equivalents are always presented alongside Windows examples, with equal detail and prominence.
  • When listing resource creation or deployment methods, alternate the order or explicitly state that all platforms are supported, and provide Bash/Azure CLI examples before or alongside PowerShell.
  • Where CLI commands are shown, provide both Windows (PowerShell/CMD) and Linux/macOS (Bash) syntax, or clarify that the Azure CLI commands are cross-platform.
  • In sections like ReadyToRun and deployment, ensure Linux examples are as detailed as Windows examples, and avoid defaulting to Windows-first explanations.
  • Review all code snippets and automation instructions to ensure parity for Linux/macOS users, including troubleshooting and debugging steps.
GitHub Create Pull Request
Azure Functions Event-driven Scaling in Azure Functions .../main/articles/azure-functions/event-driven-scaling.md
Low Priority View Details →
Scanned: 2026-01-13 06:17
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Windows First Powershell Heavy Missing Linux Example
Summary
The documentation page shows a mild Windows bias. While most examples use Azure CLI (which is cross-platform), PowerShell examples are provided as a secondary tab, and there is a specific note about scale-in behaviors that applies only to 'apps running on Windows in a Consumption plan.' No explicit Linux/macOS-specific instructions, troubleshooting, or parity notes are given. There are no references to Windows-only tools, but the documentation does not clarify platform differences or provide Linux/macOS-specific examples where relevant.
Recommendations
  • Add explicit notes clarifying that Azure CLI commands work on Linux/macOS and Windows, and provide bash/zsh shell examples if there are platform-specific considerations.
  • Where PowerShell is shown, consider providing equivalent bash or shell script examples for Linux/macOS users.
  • Clarify any platform-specific behaviors (such as the 'drain mode' note for Windows Consumption plan apps) and state whether/how they differ for Linux/macOS.
  • Add troubleshooting or configuration notes for Linux/macOS users if there are known differences in scaling or deployment.
  • Ensure that examples and instructions are presented in a platform-neutral way, or alternate between Windows and Linux/macOS examples.
GitHub Create Pull Request
Azure Functions App settings reference for Azure Functions ...ain/articles/azure-functions/functions-app-settings.md
Low Priority View Details →
Scanned: 2026-01-13 06:17
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Windows First 🔧 Windows Tools Powershell Heavy
Summary
The documentation is generally cross-platform, but there are several instances of Windows bias. Windows-specific examples (e.g., environment variable delimiters, file paths) are presented before Linux equivalents, and some settings or tools (like PowerShell and Windows-specific Node.js version settings) are described without equal Linux/macOS coverage or with Windows as the default. PowerShell is referenced as a supported runtime, but Linux shell equivalents are not mentioned. Some settings are explicitly marked as Windows-only, and Windows patterns (e.g., %HOME% for paths) are used in examples.
Recommendations
  • Present Linux/macOS examples alongside or before Windows examples, especially for environment variable delimiters and file paths.
  • Where settings are Windows-only, provide Linux/macOS alternatives or clarify equivalent settings for those platforms.
  • Include Linux/macOS shell examples (e.g., Bash) where PowerShell is referenced.
  • Avoid using Windows-centric patterns (like %HOME%) in examples without showing the Linux/macOS equivalent ($HOME).
  • Ensure that all platform-specific settings are clearly marked and alternatives are provided for other platforms.
GitHub Create Pull Request
Azure Functions Update Language Versions in Azure Functions ...n/articles/azure-functions/update-language-versions.md
Low Priority View Details →
Scanned: 2026-01-13 06:17
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Windows First 🔧 Windows Tools Powershell Heavy
Summary
The documentation generally maintains parity between Windows and Linux, but there is a consistent pattern of presenting Windows instructions and examples before Linux equivalents. Windows-specific tools and configuration patterns (such as .NET isolated worker, PowerShell, and Windows portal/CLI commands) are often described first or in more detail. Some sections (e.g., updating language versions via Azure portal or CLI) default to Windows tabs and commands, requiring Linux users to scroll or switch tabs for their instructions. PowerShell is included as a first-class language throughout, which is inherently Windows-centric.
Recommendations
  • Alternate the order of Windows and Linux instructions/examples, or present them side-by-side to avoid implicit prioritization.
  • Explicitly call out Linux/macOS compatibility in introductory sections and tool requirements.
  • Ensure all examples and instructions for updating language versions, troubleshooting, and slot management are equally detailed for Linux as for Windows.
  • Where PowerShell is referenced, provide Bash or other Linux-native shell equivalents if applicable.
  • Add a summary table at the top showing OS/language support and limitations for quick reference.
GitHub Create Pull Request
Azure Functions Storage considerations for Azure Functions ...ain/articles/azure-functions/storage-considerations.md
Low Priority View Details →
Scanned: 2026-01-13 06:17
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Windows First Powershell Heavy Minor Windows Tools
Summary
The documentation generally maintains cross-platform neutrality, but there are minor signs of Windows bias. Windows hosting plans and features are mentioned before Linux equivalents in several places, and PowerShell examples are provided alongside Azure CLI, sometimes with more detail. Some settings and scaling notes are Windows-specific, and Windows plans are referenced first in certain deployment scenarios. However, Linux-specific features (like mounting Azure Files) are clearly documented, and Linux parity is generally maintained.
Recommendations
  • Ensure Linux and macOS examples are provided alongside Windows/PowerShell examples, especially in sections describing deployment and configuration.
  • When listing hosting plans or features, alternate the order or explicitly mention Linux parity where applicable.
  • Clarify which features/settings are Windows-only and provide Linux alternatives or workarounds where possible.
  • Expand Linux-specific guidance, such as mounting file shares, with more detailed examples and troubleshooting tips.
  • Where PowerShell is used, provide equivalent Bash or Azure CLI commands for Linux/macOS users.
GitHub Create Pull Request
Azure Functions Model context protocol bindings for Azure Functions ...ain/articles/azure-functions/functions-bindings-mcp.md
Low Priority View Details →
Scanned: 2026-01-12 00:00
Reviewed by: LLM Analysis
Issues: 1 bias type
Detected Bias Types
Powershell Heavy
Summary
The documentation page includes a persistent note referencing PowerShell, likely in the form of a reusable include, but does not provide Linux/macOS-specific examples or mention Linux tools. All command-line examples use Azure CLI, which is cross-platform, and installation instructions are language-agnostic. No explicit Windows-only tools or patterns are described, but the PowerShell note may signal a subtle Windows bias.
Recommendations
  • Review the referenced PowerShell note to ensure it does not imply Windows-only support or usage patterns.
  • If PowerShell is mentioned, provide equivalent Bash or Linux/macOS shell instructions where relevant.
  • Explicitly state that Azure CLI commands work on Linux/macOS and Windows.
  • Add notes or examples for Linux/macOS users if there are any platform-specific considerations.
GitHub Create Pull Request
Azure Functions Integration and automation platform options in Azure ...ctions/functions-compare-logic-apps-ms-flow-webjobs.md
Low Priority View Details →
Scanned: 2026-01-12 00:00
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
🔧 Windows Tools Windows First Powershell Heavy Missing Linux Example
Summary
The documentation page exhibits mild Windows bias. Windows-centric tools (PowerShell, Visual Studio) are mentioned for management and development before Linux/macOS equivalents. PowerShell is listed as a management option for Logic Apps, but Linux-native tools (Azure CLI, REST API) are not emphasized equally. Visual Studio is referenced for management, while Visual Studio Code (cross-platform) is mentioned but lacks detail. There are no explicit Linux/macOS-specific examples or workflows, and the language around running scripts (e.g., .cmd, .bat) is Windows-oriented. However, most Azure services discussed are cross-platform, and workarounds (CLI, REST API, VS Code) are available.
Recommendations
  • Add explicit Linux/macOS examples for management and development tasks, such as using Azure CLI and Bash scripts.
  • List cross-platform tools (Azure CLI, REST API, Visual Studio Code) before or alongside Windows tools (PowerShell, Visual Studio).
  • Include examples of running Linux shell scripts (e.g., Bash) in WebJobs, not just Windows batch files.
  • Clarify that all management and deployment tasks can be performed on Linux/macOS using CLI and VS Code.
  • Provide parity in documentation for Linux/macOS users, including troubleshooting and environment setup.
GitHub Create Pull Request
Azure Functions Develop and run Azure Functions locally ...in/articles/azure-functions/functions-develop-local.md
Low Priority View Details →
Scanned: 2026-01-12 00:00
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Windows First 🔧 Windows Tools Powershell Heavy
Summary
The documentation shows a mild Windows bias. Visual Studio (Windows-only) is listed first and described in detail for C# development, while Linux/macOS alternatives (VS Code, command line) are mentioned but not prioritized. Windows-centric tools like PowerShell and Visual Studio are referenced before cross-platform or Linux-native options (e.g., curl, Bruno). PowerShell examples and references are present in multiple sections, and Microsoft Edge's Network Console is listed as a test tool before curl. However, most environments and tools are described as supporting Linux/macOS, and the Azurite emulator is presented as cross-platform.
Recommendations
  • List cross-platform tools (VS Code, command line) before Windows-only tools (Visual Studio) in environment tables and examples.
  • Provide Linux/macOS-specific examples or callouts where appropriate, especially for command-line usage and file paths.
  • Include Linux-native HTTP test tools (e.g., httpie, wget) alongside curl, and mention them before Windows-specific options like PowerShell.
  • Clarify when a tool or workflow is Windows-only (e.g., Visual Studio) and suggest equivalent Linux/macOS alternatives.
  • Balance PowerShell references with Bash or shell script examples for Linux/macOS users.
GitHub Create Pull Request
Azure Functions host.json reference for Azure Functions 2.x ...b/main/articles/azure-functions/functions-host-json.md
Low Priority View Details →
Scanned: 2026-01-12 00:00
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Powershell Heavy 🔧 Windows Tools Windows First
Summary
The documentation is generally cross-platform, but there are minor signs of Windows bias. The 'managedDependency' feature is described as PowerShell-only, with references to Windows-centric tools (e.g., requirements.psd1, PowerShell article). Some configuration defaults and descriptions (such as tempFolder using %TEMP% and shadowCopyFolder referencing Windows environment variables like LOCALAPPDATA, APPDATA, TEMP) are Windows-centric, with no explicit Linux/macOS equivalents or notes. In a few places, Windows patterns (e.g., environment variable syntax) are mentioned first, and Linux-specific behaviors (such as DisableColors for console logging) are described as exceptions rather than defaults.
Recommendations
  • For features like managedDependency, clarify Linux/macOS support or provide equivalent mechanisms/examples for non-Windows platforms.
  • When referencing environment variables or folders (e.g., %TEMP%, LOCALAPPDATA), also mention Linux/macOS equivalents (e.g., $TMPDIR, /tmp, $HOME/.local/share).
  • Where PowerShell is referenced, provide Bash or shell script alternatives for Linux/macOS users.
  • Explicitly state platform compatibility for features and settings, especially where defaults or behaviors differ.
  • Ensure that examples and instructions are presented in a platform-neutral order, or provide parallel examples for both Windows and Linux/macOS.
GitHub Create Pull Request
Azure Functions Use GitHub Actions to make code updates in Azure Functions ...les/azure-functions/functions-how-to-github-actions.md
Low Priority View Details →
Scanned: 2026-01-12 00:00
Reviewed by: LLM Analysis
Issues: 2 bias types
Detected Bias Types
Windows First Powershell Heavy
Summary
The documentation generally provides parity between Windows and Linux, offering workflow templates and examples for both platforms and most languages. However, there is a consistent pattern of presenting Windows options and examples before Linux equivalents, and PowerShell is included as a first-class language, which is inherently Windows-centric. Minor friction may occur for Linux/macOS users due to this ordering and emphasis.
Recommendations
  • Alternate the order of Windows and Linux examples, or present both side-by-side to avoid implicit prioritization.
  • Explicitly state Linux/macOS support at the top of the article to reassure non-Windows users.
  • Where PowerShell is mentioned, also highlight Bash or other Linux-native scripting options if relevant.
  • Ensure screenshots and instructions for portal/CLI steps are platform-neutral or include Linux/macOS variants where differences exist.
GitHub Create Pull Request
Azure Functions Use Python and TensorFlow for machine learning in Azure ...ure-functions/functions-machine-learning-tensorflow.md
Low Priority View Details →
Scanned: 2026-01-12 00:00
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Windows First Powershell Heavy 🔧 Windows Tools
Summary
The documentation provides command examples for Bash, PowerShell, and Cmd, but consistently lists Windows-specific tools and patterns (PowerShell and Cmd) before Bash/Linux equivalents. Windows-specific issues (such as long path errors and registry edits) are described in detail, while Linux/macOS troubleshooting is minimal. The use of 'py' launcher is emphasized, which is primarily a Windows tool, and Windows command syntax is often shown before Bash. However, Linux/macOS users are given sufficient instructions to complete all tasks.
Recommendations
  • Present Bash/Linux/macOS examples before Windows/PowerShell/Cmd examples, or alternate the order.
  • Expand troubleshooting sections to include common Linux/macOS issues (e.g., permissions, missing packages).
  • Clarify when tools like 'py' are Windows-only and provide explicit alternatives for Linux/macOS.
  • Ensure parity in detail and troubleshooting for Linux/macOS environments.
  • Add notes or tips for Linux/macOS users where Windows-specific advice is given (e.g., long path issues).
GitHub Create Pull Request
Azure Functions Automate function app resource deployment to Azure ...es/azure-functions/functions-infrastructure-as-code.md
Low Priority View Details →
Scanned: 2026-01-12 00:00
Reviewed by: LLM Analysis
Issues: 2 bias types
Detected Bias Types
Windows First Powershell Heavy
Summary
The documentation provides both Windows and Linux examples for most resource definitions and deployment scenarios, using Bicep and ARM templates. However, there is a notable Windows-first bias: in many sections, Windows examples are presented before Linux equivalents, and Windows terminology is often used as the default. Additionally, PowerShell is featured as a primary deployment method, with less emphasis on Linux-native tools (e.g., Bash scripts). The documentation does not omit Linux examples, and Linux-specific considerations are generally covered, but the ordering and emphasis may create friction for Linux/macOS users.
Recommendations
  • Alternate the order of Windows and Linux examples, or present Linux examples first in some sections.
  • Explicitly mention cross-platform deployment tools (e.g., Bash, Azure CLI) alongside PowerShell, and provide example Bash scripts for deployment.
  • Where possible, use neutral terminology (e.g., 'operating system' rather than 'Windows/Linux') and clarify OS-specific requirements.
  • Add a summary table or section highlighting Linux/macOS parity and any limitations.
  • Ensure that all critical steps (validation, deployment, troubleshooting) have Linux/macOS-friendly instructions and examples.
GitHub Create Pull Request
Azure Functions Guidance for developing Azure Functions ...b/main/articles/azure-functions/functions-reference.md
Low Priority View Details →
Scanned: 2026-01-12 00:00
Reviewed by: LLM Analysis
Issues: 2 bias types
Detected Bias Types
Windows First 🔧 Windows Tools
Summary
The documentation page demonstrates mild Windows bias by listing Windows-centric tools (Visual Studio) first in several sections, especially for C# development, and by mentioning Visual Studio publishing before cross-platform alternatives. However, Linux/macOS-compatible tools (Visual Studio Code, Azure CLI, Core Tools) are also consistently included, and there are no critical omissions of Linux-specific guidance or examples.
Recommendations
  • List cross-platform tools (Visual Studio Code, Azure CLI, Core Tools) before Windows-only tools (Visual Studio) to avoid implicit prioritization.
  • Explicitly mention Linux/macOS compatibility for all command-line and IDE options where relevant.
  • Where publishing/deployment is discussed, clarify parity and provide links to Linux/macOS instructions or troubleshooting.
  • Ensure that any references to 'command prompt' are clarified as 'terminal' or 'shell' to be inclusive of non-Windows environments.
GitHub Create Pull Request
Azure Functions Azure Functions Scale and Hosting .../blob/main/articles/azure-functions/functions-scale.md
Low Priority View Details →
Scanned: 2026-01-12 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 mild Windows bias. Windows-specific features and dependencies (such as PowerShell modules and .NET Framework) are mentioned as primary use cases for the Consumption plan, and Windows is often listed first in tables and descriptions. The documentation refers to Windows-specific tools and patterns before Linux equivalents, and Linux support for some plans is described as retired or limited. However, Linux hosting options are covered in detail, and Linux container support is highlighted for several plans.
Recommendations
  • Present Linux and Windows options in parallel, rather than listing Windows first in tables and examples.
  • Include Linux-specific use cases and tooling (e.g., Bash, Linux-native modules) alongside Windows/PowerShell references.
  • Avoid framing Windows dependencies as the default or primary scenario; instead, clarify platform parity and differences.
  • Provide migration guidance for users affected by Linux Consumption plan retirement.
  • Add explicit Linux/macOS example workflows where Windows-specific features (like PowerShell) are mentioned.
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
Low Priority View Details →
Scanned: 2026-01-12 00:00
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
🔧 Windows Tools Windows First Powershell Heavy Missing Linux Example
Summary
The documentation page demonstrates some Windows bias, particularly in the Java section, where command examples are provided for PowerShell and Windows CMD alongside Bash, and file path examples use Windows-style backslashes. There is also a tendency to mention Windows tools (PowerShell, CMD) explicitly, and in some cases, Windows-specific instructions or patterns are presented before their Linux equivalents. However, most core commands are cross-platform, and Bash examples are included where relevant. Some minor friction exists for Linux/macOS users due to the prominence of Windows tools and examples.
Recommendations
  • Ensure all command examples are provided for Bash/zsh (Linux/macOS) and not just PowerShell/CMD.
  • Use platform-neutral file paths or provide both Windows and Linux/macOS path examples.
  • When listing multiple shell options, present Bash (Linux/macOS) examples first or equally.
  • Explicitly mention compatibility with Linux/macOS terminals where applicable.
  • Review included files (e.g., functions-cli-create-venv.md) for any hidden Windows bias.
GitHub Create Pull Request
Azure Functions IP addresses in Azure Functions ...ocs/blob/main/articles/azure-functions/ip-addresses.md
Low Priority View Details →
Scanned: 2026-01-12 00:00
Reviewed by: LLM Analysis
Issues: 2 bias types
Detected Bias Types
Windows First Powershell Heavy
Summary
The documentation provides examples for Azure CLI, Azure PowerShell, and Azure Portal in most sections, but PowerShell examples are always present and shown after CLI, and never mentions Linux/macOS-specific tools or patterns. The use of 'nslookup' is cross-platform, but there is no explicit mention that it works on Linux/macOS, nor are alternative Linux/macOS commands (like 'dig') suggested. There is a slight Windows-first bias in the ordering and inclusion of PowerShell examples, and no Linux/macOS-specific troubleshooting or tool recommendations.
Recommendations
  • Explicitly state that 'nslookup' works on Linux/macOS and suggest alternatives like 'dig' for those platforms.
  • Add notes clarifying that Azure CLI commands work identically on Linux, macOS, and Windows.
  • Consider including Bash shell examples for querying JSON output, e.g., using 'jq' with Azure CLI.
  • Balance the inclusion of PowerShell by providing equivalent Bash or shell script examples for Linux/macOS users.
  • Where tools are mentioned (e.g., Resource Explorer), clarify platform compatibility.
GitHub Create Pull Request
← Previous Page 7 of 10 Next →