Validation

Telflo validates a configuration continuously, so problems surface before you test or deploy. Validation works at two levels: connection rules enforced on the canvas as you draw, and schema checks against the collector binary for the configuration's distribution and version.

Connection rules

Telflo enforces the component-type connection rules as you draw edges, so most graphs that break them cannot be created.

• A connection that breaks the component-type rules is refused: receivers connect outward only, exporters inward only, processors both ways, and extensions not at all.
• A connection that mismatches a connector's fixed signal types, such as spanmetrics, which takes traces in and feeds metrics out, is refused with a warning such as requires traces input. forward and routing are signal-agnostic and keep to one signal type per use; a cross-signal connection through them can be drawn, and the schema checks report it.
• The routing connector's outgoing side is not drawn. Its configuration form warns with No routes configured while its route table is empty, and with Unmatched telemetry is dropped while no default pipelines are set. See Route with the routing connector.

Everything else, including a pipeline that is missing a receiver or an exporter, is reported by the collector binary in the schema checks below.

Schema checks

Telflo validates the configuration against the real collector binary for the configuration's collector distribution and the collector version selected in the toolbar. Unknown components, unknown fields, and invalid values are reported.

A ClickStack configuration, available in private preview, is validated on the OpenTelemetry Collector Contrib build its ClickStack version is based on, with an added check that every component is one ClickStack ships. A component that is not is reported as Component 'name' (section) is not available in the ClickStack distribution. See Collector distributions.

The same collector validation is available outside the editor. telflo validate <file> --config <id> in the CLI checks a local file on the collector a stored configuration is pinned to, though a ClickStack pin is refused because the request names that distribution, telflo config push validates before it saves, and POST /validate in the API validates YAML statelessly. Through the API and CLI only OpenTelemetry Collector Contrib is offered; a request that names ClickStack is refused.

Schema validation also reports deployment requirements: values the collector needs from its environment, such as host paths or environment variables. Requirements do not block saving. They state what the deploy environment must provide.

Configuration providers

Only ${env:VAR} references are evaluated during validation. References to other configuration providers, such as ${file:...}, ${http:...}, ${https:...}, and ${yaml:...}, are replaced with placeholders before the collector validates, and the substitution is reported as a deployment requirement. The referenced files and URLs are read in the real deployment, not during validation.

The same restriction applies in the testing sandbox: non-env provider references are replaced with a placeholder before a test runs, so a test cannot read files or the network from the test environment. The substitution is listed with the run's sandbox mutations.

Organization variables

$orgvar: references to organization variables are replaced with the variables' org-default values in a transient copy before the collector validates, and the same substitution applies to test runs started from the Testing tab and to the AI assistant's own validation and test tools. The stored configuration keeps its tokens, and variable-group overrides are not applied during validation or testing; they are resolved when each collector checks in.

Validation and test runs started through the Telflo API or the CLI send the YAML as written: $orgvar: tokens are not substituted, and the test sandbox collector rejects them. To test a configuration that uses organization variables from the CLI, run the test on a local copy with the values filled in, or run it from the Testing tab.

Validation status

The editor shows a status row with the result: config valid with the collector version, or the number of errors. When there are errors, expand the row to see each one, with the affected component and a description. Deployment requirements appear in their own row beneath it, whether or not the configuration is valid; expand it to see each requirement's title and description and, where it applies, the component.

If the validation service itself cannot be reached, the row shows validation unavailable · config not checked with the reason, for example Validation service unavailable (cannot connect to the validator). Your YAML was not checked — retry shortly. The configuration is then unchecked rather than invalid: saving and applying YAML edits stay possible, and the check runs again on your next change. A configuration that was last checked during an outage has not been validated by a collector. Two answers from the validator are reported as errors rather than as an outage, because they are verdicts on the configuration: Collector version X is not supported. and Binary for version X is not available on the validator. Select a supported collector version in the toolbar to clear them. The same outage is reported to the CLI as exit 1 with could not validate, and to the AI assistant, which skips its binary check and says so.

While you edit YAML manually, the canvas shows Yaml is Valid when the edits pass, Errors must be corrected. when they do not, or Validation unavailable — YAML not checked. during an outage. Edits with errors cannot be applied to the canvas until every error is resolved; unchecked edits can, with the Apply button's tooltip reading Validation unavailable — applying unchecked YAML.

If validation requests are rate-limited, the row reports one error, Validation rate limited. Will retry automatically., and Apply is disabled until the next check succeeds.

OTTL expressions

Collector validation parses the OTTL statements and conditions in transform, filter, routing, and tail_sampling components as part of the schema checks. For a faster check that points at each expression, the CLI has telflo ottl lint config.yaml, which parses the OTTL expressions in a configuration with the collector's OTTL grammar and reports the YAML location of each problem; routing rules in the request context and legacy route statements are listed as skipped rather than checked. It also rejects single-escaped regex sequences such as "\d", which parse but never match, and it checks raw expressions with --context and --expr. Nothing is executed. The same check is available as POST /ottl/lint in the API.

Validation and testing

Validation answers whether a configuration is well-formed and valid. To check what a configuration does to real data, run a test. See Testing.