
The run history is what I use most. Our Playwright CI jobs report into Qase, so each Business, Admin, and Mobile suite gets its own run instead of living only in a GitHub log. I open the dashboard, see which suite passed or failed, and open the failed case. Last week that was a Business portal login timeout on one run and a Mobile profile-activity check on another. A later Business portal run the same morning was green, and having both runs side by side made it obvious the first one was a session flake, not a product break. I also keep the run id when I write the Slack update or a Jira comment, so someone else can open the same result without me pasting a log. Review collected by and hosted on G2.com.
A cancelled CI job leaves the run empty. The reporter opens the Qase run when the job starts, and if GitHub cancels the job before it publishes results, the run stays In Progress with no cases and a 0 duration. Our weekly Admin portal jobs did this, so the dashboard showed runs that looked active when nothing had been executed. Closing or marking the run aborted when the job is cancelled would keep the history honest.
The results API is the other gap. I can list runs with the same token, but fetching results for the project returned 403. I then had to open each run in the UI, or go back to the GitHub log, to see which case failed. The token that can list runs should be able to read the results on those runs. Review collected by and hosted on G2.com.