Repository navigation
Idea: Add "log watcher/fixer" sample workflow to analyze OpenTelemetry #297
Description
Activity
- changed the title
[-]Idea: Add sample workflow to analyze OpenTelemetry[/-][+]Idea: Add "log watcher/fixer" sample workflow to analyze OpenTelemetry[/+]on Mar 26, 2026 Yeah we'd love some contributions along these lines.
Authorization to access the telemetry data from an automated GitHub Action is usually a significant component of the work needed for this kind of workflow.
At GitHub we've successfully pointed workflows at production telemetry data (mediated by safe networking access) for performance and incident investigation.
There are design questions aroud triggers, cadence, and reporting.
Reacted by Paul BeigangThe authorization point is a real consideration for external OTel endpoints. One angle that sidesteps it:
token-usage.jsonlis already written locally by the gh-aw firewall per run, so a cost and token observability workflow has no external telemetry auth to solve. Cost variance detection (spikes, cache efficiency drops, model drift) fits the same reactive pattern and the data is already there.I've been building cost tracking tooling for gh-aw runs and would be happy to contribute something along these lines, especially if it helps clarify the trigger/cadence/reporting design questions in a simpler context first.
@adamhenson we'd love your contribution.
Add an example workflow how to use OpenTelemtry data as trigger and or context for agentic workflows.
Thinking in a direction of fixing all warnings automatically :)