Expand AL-Go telemetry dashboard

[Jose M. Martinez (jmanuelmartinez)]

❔What, Why & How

Expands the starter Azure Data Explorer dashboard with dedicated views for workflow reliability, run exploration, test quality, workflow duration, runner efficiency, and AL-Go maintenance.

The dashboard also adds repository, workflow, branch, and repository-type filtering, clearer empty states, and repository-level runtime supportability information. It was imported and exercised against representative AL-Go telemetry, and all repository pre-commit hooks pass.

Related to issue: N/A

✅ Checklist

• Add tests — not applicable because this is a static Azure Data Explorer dashboard export; it was imported and exercised against representative telemetry
• Update RELEASENOTES.md
• Update documentation
• Add telemetry — not applicable because the dashboard consumes existing AL-Go telemetry and does not introduce new emitted events

[Jose M. Martinez (jmanuelmartinez)]

@microsoft-github-policy-service agree

[Copilot]

Pull request overview

Expands the starter Azure Data Explorer dashboard with reliability, test-quality, runtime, runner, and maintenance insights.

Changes:

• Adds dashboard pages, filters, queries, and caching.
• Documents dashboard usage and sensitive telemetry handling.
• Adds release notes.

Reviewed changes

Copilot reviewed 2 out of 3 changed files in this pull request and generated 3 comments.

File	Description
Scenarios/resources/telemetrydashboard.json	Expands dashboard visuals, filters, and telemetry queries.
Scenarios/EnablingTelemetry.md	Documents dashboard setup and behavior.
RELEASENOTES.md	Announces the expanded dashboard.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Alexander Holstrup (aholstrup1)]

Don't forget to take the PR out of draft mode when it is ready :)

I took the opportunity to take a brief look at what you've done, and I think it looks great 🚀 This is quite a nice improvement to the dashboard, so thanks for contributing that!

While looking at it, did you find any signals you were missing in the telemetry? Some information you wanted to display that we don't currently emit telemetry for? Not something I expect you to add in this PR. Just wanted to hear your opinion while you were looking at this :)

[Jose M. Martinez (jmanuelmartinez)]

Thanks for the feedback Alexander Holstrup (@aholstrup1) , I really appreciate it! 🤜🤛

I’ve been working on improving the dashboard because of the number of repos we manage across our organisation (100+), and I love that you asked this. A few gaps became particularly noticeable while I was building and testing it.

I’ll try to put my thoughts down as clearly as I can, but I’m very happy to expand on any of these ideas:

1. Job lifecycle timing and correlation: GitHub’s API and workflow_job webhooks can provide job queue and execution timing, while AL-Go telemetry gives us the duration of individual actions. What appears to be missing is a reliable way to connect the two at job level. A stable job-level identifier in the AL-Go telemetry, alongside the existing run information, would allow the dashboard to separate the time spent waiting for a runner, the time the job was executing and the time spent within or outside individual AL-Go actions. That distinction is important when managing many repos. Two workflows might both take 20 minutes, but one could spend 12 minutes waiting and only eight minutes running, while the other might use the runner for the full 20 minutes. The first points towards needing more runner capacity; the second suggests that the build itself needs optimising.

2. A clear test execution state: Test telemetry tells us when tests execute, but when there is no event, we don’t know why. Tests might have been disabled, no tests might have been discovered, or the expected telemetry might not have been produced. An explicit state such as “No tests executed: disabled by configuration” would be far more useful than an empty chart, especially when using the dashboard as a quality and governance view across multiple customer repos.

3. Structured failure details: AL-Go already knows which action is running when something fails, but the dashboard currently has to extract that information from the telemetry message text. Having structured fields such as ActionName, and potentially FailedJob or ActionConclusion, would make this much more reliable. It would let us quickly see patterns such as 22 failures during compilation, 11 during testing and five during dependency download, without having to inspect each workflow run individually.

If any of these ideas sound interesting from your side, I’d be very happy to open a separate PR with a more detailed technical proposal for expanding those signals 🫡 I

I’m also happy to provide any further context or clarification.

Thanks again for all the work you’re putting into AL-Go. It’s great to see the level the project is reaching! 💪