Context

When implementing observability into control planes, you may want to understand what types of failures and events can be captured and monitored. This includes both failures that occur within function pods and failures that happen at the provider level when interacting with cloud services.

Answer

Control plane observability collects logs and metrics from all user-facing control plane workloads, including Crossplane, functions, and providers. What you can observe depends on the type of failure and where it is surfaced.

Function Failures

Failures in function pods (such as bad parameters, logic errors, or exceptions) are observable primarily through logs. We collect logs from all control plane pods, including function pods. The exact error details you'll see depend on what the function and Crossplane log, as they are intentionally conservative with log output, but function failures should generally be visible via logs.

Provider Failures

Provider-level failures (such as AWS returning AlreadyExists, invalid VPC IDs, or permission errors) behave differently:

• Providers typically do not log detailed cloud API error messages

• These errors are surfaced most reliably in the managed resource status and conditions (e.g. via kubectl get <resource> -o yaml)

• From an observability perspective, you can see the impact via generic reconciliation error metrics (for example, controller_runtime_reconcile_errors_total), which indicate failing reconciles but do not include detailed cloud API error context

Available Metrics

The list of currently exposed metrics from Crossplane, providers, and functions is documented at:

• https://docs.crossplane.io/latest/guides/metrics/

For more detailed or custom metrics, there is ongoing upstream work in Crossplane that may expand observability capabilities in the future.