How to Set Up Working-Time Tracking for Your Dev Team

If you can’t see how long verification work actually takes, you can’t plan releases, balance load, or defend a “yes, it was tested” with evidence. This tutorial shows how to set up working-time tracking for your dev team in KazTrack — starting and stopping session timers on real pull requests and turning that data into reports by tester, day, repository, and label. No stopwatches, no after-the-fact guessing.

What Working-Time Tracking Gives You

KazTrack tracks time as testing sessions: a tester starts a timer when they begin working a pull request and stops it when they’re done. Those sessions roll up into reports that answer practical questions:

• How much time did each tester log this week?
• Which repository eats the most verification time?
• How long did a specific pull request take to verify?
• How much effort is going into failed work versus passed?

It’s built on the work your team already does on GitHub, so tracking time doesn’t add a separate ritual.

Prerequisites

• A KazTrack project with at least one repository connected.
• Team members invited with appropriate roles (tester is enough to log sessions; manager/owner can view all reports).
• A few open pull requests to track against.

Step 1: Confirm Members Can Log Sessions

Working-time tracking is permission-gated. Before your team starts:

1. Open Members in your project.
2. Make sure each person who’ll track time has a role that includes the session logging permission — the built-in tester, manager, and owner roles all do.
3. Confirm that the people who need to read team-wide reports have a role with the reports-view permission (typically manager or owner).

A handy detail: a member who can log sessions but can’t view all reports is automatically scoped to their own data. They see their time, not everyone’s.

Step 2: Start a Session on a Pull Request

This is the day-to-day action every tester takes:

1. Open the Pull Requests list and pick the PR you’re about to test.
2. Click to start a testing session. The timer begins immediately.
3. Do the work — walk the diff, run any attached test cases, record results.

Each session ties one tester to one pull request with a start timestamp. Until you stop it, the session counts as in progress (its end time is open).

One session, one PR, one tester

Sessions are deliberately simple: a single tester, a single pull request, a start and an end. That simplicity is what makes the reports trustworthy later — there’s no ambiguity about who spent time on what.

Step 3: Stop the Session When You’re Done

1. When testing wraps, stop the session. KazTrack records the end timestamp.
2. Set the workflow label (passed / failed) as usual — this syncs to GitHub and posts a comment, but it’s the session that captured your time.

If someone forgets to stop a session, it simply stays open. Encourage the team to stop sessions as part of “done,” the same way they’d push a commit.

Step 4: Read the Reports

Now the payoff. Open the Reports area and explore the breakdowns. Each one answers a different planning question:

Report by tester

See total logged time per person. Use it to balance load — not to rank people. If one tester is carrying twice the verification hours, that’s a staffing signal, not a performance verdict.

Report by day

A timeline of effort across the team. Great for spotting crunch before a release or a quiet patch that means work isn’t flowing in.

Report by repository

Which services cost the most to verify? A repository that consistently soaks up time may need better tests, clearer specs, or refactoring.

Report by pull request

Time spent on a specific PR. This is your evidence trail — when someone asks “was this really tested?”, you can show the logged verification time.

Report by label

Time grouped by workflow label. If a lot of hours land on failed, you’re learning something about flaky features or unclear requirements before they reach production.

Step 5: Build a Lightweight Team Routine

Tracking works best as a habit, not a policy. A routine that tends to stick:

1. Start a session when you pick up a PR — make it the first click, like opening the diff.
2. Stop it when you set the workflow label — pair “I’m done” with “timer off.”
3. Review reports weekly — managers skim by-tester and by-day to plan the next sprint, and by-repository to find time sinks.

Keep the framing positive. The point is visibility and fair planning, not surveillance. Teams that present it as “this is how we prove our work and balance the load” get clean data; teams that present it as monitoring get gamed numbers.

Troubleshooting

A session won’t start. Check that the member’s role includes the session-logging permission, and that the pull request belongs to the current project.

A tester can’t see team reports. That’s expected if they only have session-logging permission — they’re auto-scoped to their own data. Grant a reports-view role if they need the team view.

Times look too long. Look for sessions left open. An un-stopped session keeps counting; closing it corrects the report.

Key takeaways

• Working-time tracking in KazTrack is built on simple start/stop sessions — one tester, one pull request, a clear start and end.
• Reports break down by tester, day, repository, pull request, and label, so you can balance load and prove verification effort.
• Make starting and stopping sessions part of the team’s “done” routine, and frame it as visibility, not surveillance.

Want to know exactly where your team’s verification time goes? Set up testing sessions in KazTrack today and turn release planning from guesswork into something you can actually measure.