>Is 'Mean Time to Resolution' the definition for 'mttr' in latter endpoint?

It is and is calculated from the first failed run to the next successful run.

>Would it be possible to add more details about definitions / how some of the metrics were calculated?

I will update the current document to add more details.

Thank you so much for your feedback.

Thanks Kunal.

We like having access to the credits_used per workflow endpoint and have made use of that.

With the wider Insights endpoint we're still in the 'testing the waters' phase.

Is 'Mean Time to Resolution' the definition for 'mttr' in latter endpoint?

Related: those preview docs are helpful; would it be possible to add more details about definitions / how some of the metrics were calculated?

Insights API is in public preview. More information on how to access API can be found on the following document:

Any feedback would be appreciated. Please reach out at . Thanks!

We in the process of building Insights API which is going to provide this data. Please feel free to reach out to with your GitHub or Bitbucket organization name and we can add to the preview list.

please add this - job insights are worthless for us, we just want to see the overall trend for our full suite.

Yes please, this is a must-have for Insights page -- we need to be able to track successful workflow completion times over time to understand our build health trend.

Related suggestions that help understanding workflow completion time trends:

* number of tests run across all jobs (if this increases a lot then a slower workflow doesn't necessarily mean there's another issue)

* docker image / artifact sizes (maybe base and total separately) -- same as above, this helps understanding trends.

Insights is currently not very helpful for folks who are using workflows, because it's based on job timings. Hope you'll be able to provide feature parity soon!

Thanks,

Andre