GitHub Actions Telemetry

A repository can spread its delivery work across several GitHub Actions workflows. Looking at one green check tells only part of that story. This reusable action gathers workflow, job, and step information for a commit and turns it into a structured report.

The observer is an original Python-based composite action. It works through GitHub’s API instead of requiring telemetry steps inside every target workflow. The result is a separate observation layer, with useful limits around polling, commit correlation, and token permissions.

Observing without editing workflows

The action definition installs Python 3.11 and requests, reads the repository and commit SHA from the caller’s GitHub context, and accepts a token and optional reporting settings. The implementation queries Actions endpoints to enumerate workflows and retrieve runs, jobs, and steps.

Commit identity is the main correlation key. This is helpful when several workflows respond to one push, but it is different from tracing one specific event or run. Re-runs and different events attached to the same SHA can belong to the same observed group.

Waiting for the run set

The observer implementation delays before polling so it does not immediately conclude that no work exists. Defaults include a 60-second initial delay, 15-second polling interval, a 30-second run-count stability period, and a maximum wait of one hour.

Discovery first waits for the run count to stabilize; a separate loop then waits for the discovered runs to finish. Completed jobs remain available through the API, so short jobs do not simply disappear between polls. A downstream run that starts after the observer finishes can still be absent, and pending work can exhaust the timeout. The report also selects one run per workflow, rather than preserving every re-run for a SHA.

From API responses to reports

The observer writes JSON containing status, timing, and commit context. An optional HTTP integration sends that payload to another API using bearer authentication. Posting failures are caught, so an unavailable reporting endpoint does not necessarily fail the action.

The SVG renderer converts the payload into a stacked workflow and step-status view. It is a status overview, rather than a time-proportional Gantt chart. Sample JSON and a committed SVG make the output inspectable without operating a separate dashboard service.

Permissions and retention

Read-only collection needs Actions and repository read access. The repository’s own workflow uses broader permissions because it can commit a refreshed SVG and remove earlier cancelled or skipped observer runs.

That cleanup setting has a real retention effect: it calls the workflow-run deletion API. It should be an explicit choice for a consuming repository, not an invisible prerequisite to gathering telemetry. The API key and endpoint settings also define where the collected metadata can leave GitHub.

Integration boundaries

The example workflows exercise several trigger types, including an intentionally failing job and downstream workflow_run activity. They are useful test scenarios, but source inspection exposes two integration gaps. The README consumes json_path and svg_path as action outputs, while the composite action does not declare the output mapping that would expose them to callers.

For workflow_run, the observer workflow passes github.sha rather than explicitly selecting the triggering run’s head_sha. That can select a different commit from the upstream run. Correcting those contracts, and escaping workflow names before inserting them into SVG XML, would strengthen the action before broader reuse. No adoption or performance figures are claimed here.

Source files

• action.ymlInputs, credentials, runtime, and composite-action contract.
• observer.pyPolling, correlation, JSON collection, and optional delivery.
• generate_svg.pyReport rendering and SVG structure.
• Observer workflowTrigger wiring, permissions, artifact handling, and cleanup.