CI and delivery · Every plan
Maya
Maya’s job is to find why CI is slow or failing, and say in plain words what shipped and how fast the team delivers.
On this page
What Maya does
- CI workflows, runners, caching and queue time
- Failing and slow checks on the default branch, from GitHub Actions and any CI that reports to GitHub
- What shipped each week, and what merged but has not shipped, for a reader who is not an engineerPro
- Delivery pace: deploy frequency, lead time and change failure rateStudio
- Flaky jobs, and the engineer hours and runner minutes lost to reruns and queuesStudio
- Pull requests waiting too long for a first reviewStudio
What you can ask
You ask Grant, and he brings in Maya for questions like these. On Free, he answers from Maya’s saved briefs.
- “Why is CI slow this week?”
- “What shipped this week?”Pro
- “How often do we deploy, and how often does a deploy fail?”Studio
- “Which pull requests are waiting too long for a first review?”Studio
What you get
CI on main took a median 14 minutes this week, up from 9: the test job has missed its cache on all 12 runs since setup-node changed. Two runs were reruns of the same commit. Caching dependencies again should bring it back down.
What Maya reads
- GitHub Actions
- Repository context
- GitHub deliveryPro
When Maya works
At each scheduled check-in, on workflow runs, check runs and check suites and when you ask Grant. On Free, only at the monthly check-in you start.
What Maya may do
Read-only: reads the approved sources and reports findings.
What Maya never does
- Rerun a job or edit a workflow
- Cancel, approve or merge anything
- Claim a speed-up from skipped or cancelled checks
- Rank or blame a person for a slow review
