Your Software Development Lifecycle Data Template

GitHub
Your Software Development Lifecycle Data Template

Your Software Development Lifecycle Data Template

This template provides a comprehensive guide for collecting and preparing your Software Development Lifecycle data from GitHub. You will find recommended attributes to include, essential activities to track, and practical guidance for data extraction. Use this resource to build an accurate event log for effective process analysis and optimization.
  • Recommended attributes to collect
  • Key activities to track
  • Extraction guidance
New to event logs? Learn how to create a process mining event log.

Software Development Lifecycle Attributes

These are the recommended data fields to include in your event log for comprehensive Software Development Lifecycle analysis and process discovery.
3 Required 5 Recommended 16 Optional
Name Description
Activity
ActivityName
The name of a specific event or task that occurred within the software development lifecycle.
Description

The Activity Name describes a single step in the development process, such as 'Issue Created', 'Code Pushed to PR', 'Pull Request Approved', or 'Deployment Succeeded'. These events form the sequence of steps that constitute the end-to-end process for a development item.

This attribute is fundamental to process mining as it is used to construct the process map. Analyzing the sequence, frequency, and duration of these activities reveals the actual process flow, identifies common paths, highlights deviations, and pinpoints bottlenecks.

Why it matters

This attribute forms the backbone of the process map, allowing for the visualization and analysis of the sequence of events in the development lifecycle.

Where to get

Derived from the 'action' field of webhook event payloads (e.g., 'opened', 'closed' for an issue) or from the event type itself (e.g., 'PushEvent', 'PullRequestReviewEvent').

Examples
Issue CreatedPull Request OpenedCode Pushed to PRReview RequestedPull Request Merged
Development Item
DevelopmentItemId
The unique identifier for a single unit of development work, such as a feature, bug fix, or task. This serves as the primary case identifier.
Description

The Development Item ID tracks a work item from its creation to final deployment. It links all associated activities, such as branch creation, commits, pull requests, reviews, and deployments, into a single, cohesive process instance.

In analysis, this ID is used to calculate the end-to-end cycle time of a development task. It allows for the reconstruction of the entire journey of a feature or bug fix, enabling detailed analysis of bottlenecks, rework loops, and process variations for individual work items.

Why it matters

It is the essential key for process mining, connecting all related development events into a single case to accurately visualize and analyze the end-to-end software development lifecycle.

Where to get

This is typically the Issue Number or Pull Request Number from GitHub. It can be extracted from the 'number' field in the payload of issue or pull request related webhook events or API responses.

Examples
101PR-2345TASK-812
Start Time
EventTimestamp
The exact date and time when a specific development activity or event occurred.
Description

This timestamp marks the beginning of an activity. It is crucial for ordering events chronologically to reconstruct the process flow for each development item. The sequence and time difference between these timestamps are used to analyze process performance.

In analysis, this attribute is essential for calculating all time-based metrics, including cycle times, processing times, and waiting times. It enables the identification of delays between steps and provides the data needed for bottleneck analysis and performance monitoring dashboards.

Why it matters

This timestamp is critical for ordering events correctly and calculating all performance metrics, such as cycle times and bottleneck durations.

Where to get

Typically found as 'created_at' or 'updated_at' fields in the JSON payloads from GitHub APIs and webhooks for various objects like issues, pull requests, and commits.

Examples
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:25Z
Assigned User
Assignee
The user or developer assigned to handle the development item or a specific task, like a pull request review.
Description

This attribute identifies the individual responsible for the work at a given stage. This could be the assignee of an issue, the author of a pull request, or the reviewer requested for a code review. Tracking the assignee is key to understanding resource allocation and workload.

This attribute is used in analysis to monitor developer workload, identify resource bottlenecks, and analyze handoff efficiency between different team members. Dashboards can be filtered by assignee to assess individual or team performance and ensure a balanced distribution of work.

Why it matters

Crucial for analyzing developer workload, team performance, and the efficiency of handoffs between different team members.

Where to get

Available in the 'assignee' or 'user' object within the JSON payloads for issues, pull requests, and review events from the GitHub API.

Examples
john.doejane.smithdev-team-lead
Development Item Type
DevelopmentItemType
The classification of the development work item, such as a feature, bug, task, or epic.
Description

This attribute categorizes the nature of the work being done. This information is typically managed through labels or specific issue templates within GitHub. Understanding the type of work is crucial for setting appropriate performance expectations, as a bug fix might have a much shorter expected cycle time than a new feature.

This attribute enables comparative analysis between different work types. It helps to analyze if bug fixes are processed faster than new features, or to understand the resource allocation for technical debt versus new development. It is a key dimension in the 'Throughput by Project and Type' dashboard.

Why it matters

Categorizes work items, enabling performance comparisons and analysis of how different types of work (e.g., bugs vs. features) flow through the process.

Where to get

Typically derived from GitHub labels applied to issues or pull requests. Requires a consistent labeling convention (e.g., 'type:bug', 'type:feature').

Examples
BugFeatureTaskTechnical Debt
End Time
EndTimestamp
The exact date and time when a specific development activity or event was completed.
Description

The end timestamp marks the completion of an activity. While many events in GitHub are instantaneous (e.g., 'Issue Created'), some activities have a measurable duration (e.g., a CI check running). The difference between the End Time and Start Time yields the processing time for an activity.

This attribute is used to calculate the 'ProcessingTime' metric, which is vital for understanding how much active effort is spent on different tasks like code reviews or automated checks. Analyzing processing times helps identify inefficient activities that are consuming too much time.

Why it matters

Enables the calculation of precise processing times for activities, helping to distinguish between active work time and idle waiting time.

Where to get

Can be found as 'completed_at' in check run objects or derived from the timestamp of a subsequent, logically-concluding event.

Examples
2023-10-26T10:05:15Z2023-10-27T18:00:00Z2023-10-28T09:10:30Z
Priority
Priority
The priority level assigned to a development item, such as 'High', 'Medium', or 'Low'.
Description

Priority indicates the urgency or business importance of a work item. In GitHub, priority is not a native field and is typically managed using labels (e.g., 'P1-High', 'P2-Medium'). A consistent labeling scheme is required to extract this information reliably.

This attribute is essential for 'Priority-Based Flow Analysis'. It allows analysts to verify if high-priority items are actually processed faster than low-priority items and to measure the cycle time variance based on priority. It helps in evaluating the effectiveness of the prioritization process.

Why it matters

Enables analysis of whether high-priority items are processed faster than lower-priority ones, validating the effectiveness of the prioritization strategy.

Where to get

Derived from GitHub labels applied to issues or pull requests. It requires a standardized convention for priority labels.

Examples
HighMediumLowCritical
Repository
RepositoryName
The name of the code repository where the development activity is taking place.
Description

The repository acts as a project or product identifier, containing all the code, issues, and pull requests for a specific application or component. It provides a way to segment and compare development processes across different products or teams.

In analysis, this attribute allows for filtering and comparing process performance across different projects. It helps answer questions like, 'Which project has the longest cycle time?' or 'How does the bug fix process in Project A compare to Project B?'. It is essential for the 'Throughput by Project and Type' dashboard.

Why it matters

Allows for the segmentation and comparison of development processes across different projects, products, or teams, enabling more targeted analysis.

Where to get

Available in the 'repository' object in nearly all GitHub webhook and API payloads. The specific field is typically 'repository.full_name' or 'repository.name'.

Examples
my-org/web-appmy-org/api-servicemy-org/data-pipeline
Author
Author
The user who created the issue, pull request, or commit.
Description

The author is the originator of a specific artifact in the development process. For example, the author of an issue is the person who reported the bug or requested the feature. The author of a pull request is the developer who wrote the code.

In analysis, the author can be used to understand the sources of work. For instance, analyzing the authors of bug reports might reveal patterns related to specific teams or features. It can also be used in conjunction with the assignee to analyze handoff patterns.

Why it matters

Identifies the originator of a work item or code change, which can be useful for analyzing sources of rework, bug reports, or feature requests.

Where to get

Available in the 'user' object within the main object of API responses for issues, pull requests, and commits. The field is typically 'user.login'.

Examples
sara.jonesmike.leeautomation-bot
Branch Name
BranchName
The name of the Git branch where the code changes for the development item were made.
Description

A branch is an independent line of development, created to work on a new feature or bug fix without affecting the main codebase. The branch name often contains useful information, such as the issue number or a short description of the work.

Analyzing branch names can help in understanding branching strategies and adherence to development conventions. It also helps in linking specific code commits to a development item, providing a complete picture of the coding activity.

Why it matters

Provides context about the specific line of development and helps in enforcing and analyzing branching strategies and naming conventions.

Where to get

Available in the 'ref' field for push events, or in the 'head' and 'base' objects within a pull request API response.

Examples
feature/PROJ-123-new-loginbugfix/fix-payment-bughotfix/critical-security-patch
CI Check Status
CiCheckStatus
The status of an automated Continuous Integration (CI) check, such as 'passed' or 'failed'.
Description

This attribute reflects the outcome of automated builds, tests, and scans that run against code changes in a pull request. CI checks are a critical quality gate in modern development workflows.

Analyzing this attribute helps to understand the effectiveness of automated testing. A high failure rate might indicate problems with code stability, the testing suite, or the development environment. It supports the 'CI Checks Passed' and 'CI Checks Failed' activities and helps in analyzing delays caused by broken builds.

Why it matters

Indicates the success or failure of automated quality gates, providing insight into code quality and the effectiveness of the CI pipeline.

Where to get

Obtained from the 'state' or 'conclusion' field of check run or status objects via the GitHub Checks or Statuses API.

Examples
successfailurependingerror
Commit Hash
CommitHash
The unique identifier (SHA) for a specific code commit.
Description

A commit hash is a 40-character SHA-1 hash that uniquely identifies a commit in Git. It acts as a permanent ID for a specific version of the code. Commits are the atomic units of change in the development process.

While highly granular, the commit hash provides the ultimate level of traceability. It allows analysts to link a process event directly back to the exact code change that was made. This can be invaluable for auditing, compliance, or detailed root cause analysis of production incidents.

Why it matters

Provides the most granular link between a process step and the exact code change, enabling full traceability for audits and debugging.

Where to get

Available in push event payloads ('head_commit.id') or via the Commits API for a pull request or branch.

Examples
a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0f0e9d8c7b6a5f4e3d2c1b0a9f8e7d6c5b4a3f2e1
Deployment Environment
DeploymentEnvironment
The target environment for a deployment, such as 'Staging' or 'Production'.
Description

This attribute specifies where the code is being deployed. Tracking deployments to different environments is key to understanding the full lifecycle, from development to production release.

This attribute allows for analyzing the deployment sub-process. It can be used to measure the time it takes to promote code from staging to production and to track the success rate of deployments to different environments. It is essential for knowing when a development item is truly 'done' and delivered to users.

Why it matters

Distinguishes between pre-production and production releases, which is critical for measuring the true 'time-to-market' and analyzing deployment patterns.

Where to get

This information is retrieved from the GitHub Deployments API, which is often triggered by CI/CD pipelines or other automation.

Examples
developmentstagingproduction
Development Cycle Time
DevelopmentCycleTime
The total time elapsed from the creation of a development item to its final deployment or closure.
Description

This is a case-level metric calculated as the time difference between the very first event (e.g., 'Issue Created') and the final event (e.g., 'Deployment Succeeded' or 'Issue Closed') for a single development item.

This is one of the most important KPIs for measuring the overall efficiency of the development process. It directly supports the 'Overall Development Cycle Time' dashboard and the 'Average Development Cycle Time' KPI. Reducing this metric is often a primary goal of process improvement initiatives.

Why it matters

Represents the end-to-end 'time-to-market' for a development item, making it a critical KPI for measuring overall process velocity and efficiency.

Where to get

Calculated at the case level by subtracting the timestamp of the first activity from the timestamp of the last activity.

Examples
P5DT6H30MP14DT12HP1DT2H
Handoff Waiting Time
HandoffWaitingTime
The calculated idle time a development item spends waiting between activities performed by different people.
Description

This metric measures the time between the completion of one activity and the start of the next, but only when the person responsible changes. For example, the time between a 'Review Requested' event and a 'Changes Requested in Review' event by a different user.

This is a critical metric for identifying communication gaps and coordination problems. It supports the 'Critical Handoff Efficiency' dashboard and the 'Average Handoff Waiting Time' KPI. High waiting times at handoff points are often a sign of resource constraints or inefficient notification processes.

Why it matters

Pinpoints delays caused by poor coordination or resource unavailability during handoffs between different teams or roles, which are often major sources of inefficiency.

Where to get

Calculated by identifying sequential activities where the 'Assignee' or 'User' attribute changes, and then measuring the time gap between them.

Examples
PT1H15MP2DT4HPT25M
Is Rework
IsRework
A boolean flag that is true if an activity represents a regression to a previous process stage.
Description

This flag is set to true when a development item moves backward in the process, for example, when a pull request receives a 'Changes Requested' review, or when an issue is reopened after being closed. It is derived by analyzing the sequence of activities.

This attribute is essential for quantifying waste and inefficiency. It directly supports the 'Rework and Regression Loops' dashboard and the 'Rework Rate' KPI. By filtering on 'IsRework = true', analysts can isolate and investigate the causes of rework.

Why it matters

Explicitly flags activities that constitute rework, making it easy to quantify, visualize, and analyze the causes of process inefficiencies.

Where to get

This is a derived attribute. The logic involves defining a standard process flow and then flagging any activity that deviates by returning to an earlier logical stage.

Examples
truefalse
Item State
State
The current status of an issue or pull request, such as 'open', 'closed', or 'merged'.
Description

This attribute indicates the high-level status of a development item. For issues, the typical states are 'open' and 'closed'. For pull requests, states include 'open', 'closed', and 'merged'. This provides a snapshot of the item's progress.

In analysis, the state is used to identify active versus completed work. It is essential for dashboards like 'Active Development Progress' which monitor ongoing work. It is also used to define the end of a process, for example, a state of 'merged' or 'closed' might signify the completion of a case.

Why it matters

Provides a clear indication of whether a work item is currently in progress or completed, which is fundamental for lifecycle analysis and monitoring active work.

Where to get

Directly available as the 'state' field in the JSON payloads for issues and pull requests from the GitHub API.

Examples
openclosedmerged
Labels
Labels
A list of tags or labels applied to an issue or pull request for categorization.
Description

Labels in GitHub are a flexible way to add metadata to issues and pull requests. They can be used to denote priority, work type, components, teams, or status. The raw list of labels provides rich, unstructured context.

While specific attributes like Priority and Type are derived from labels, retaining the full list can be useful for ad-hoc analysis and discovering other process patterns. It allows for flexible filtering and segmentation of cases based on any combination of labels.

Why it matters

Provides a flexible, rich source of metadata for categorizing work items, enabling deep and varied dimensional analysis.

Where to get

Available as the 'labels' array in the JSON payload for issues and pull requests from the GitHub API. Each item in the array is an object with a 'name' field.

Examples
bug, ui, high-priorityfeature, backend, needs-docstech-debt, refactor
Last Data Update
LastDataUpdate
The timestamp indicating when the data for this record was last refreshed from the source system.
Description

This attribute records the date and time of the most recent data extraction or update. It provides metadata about the freshness of the data being analyzed. This is distinct from the event timestamp, which records when the business event happened.

In analysis, this field is crucial for understanding the timeliness of the process view. It helps users know if they are looking at real-time data or a snapshot from a specific point in time, which is important for operational dashboards and monitoring.

Why it matters

Indicates the freshness of the data, which is critical for ensuring that analyses and dashboards are based on up-to-date information.

Where to get

This timestamp is generated and added during the data extraction, transformation, and loading (ETL) process.

Examples
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
Processing Time
ProcessingTime
The calculated duration of an activity, representing the active work time.
Description

Processing Time is the elapsed time between the start and end of an activity. It is calculated as 'EndTimestamp' minus 'EventTimestamp'. This metric measures how long it takes to complete a task, excluding any time spent waiting for the task to begin.

Analyzing processing time helps to identify which activities are the most time-consuming in terms of active effort. This is different from cycle time, which includes waiting time. For example, a code review might have a long cycle time but a short processing time, indicating the reviewer is busy and the PR is waiting in a queue.

Why it matters

Measures active work duration, helping to distinguish between time spent working on a task versus time spent waiting for it, which is key for targeted efficiency improvements.

Where to get

Calculated by subtracting the 'EventTimestamp' from the 'EndTimestamp' for a single activity record.

Examples
PT5M15SPT2H30MP1DT12H
Pull Request Number
PullRequestNumber
The unique identifier for a pull request associated with the development item.
Description

A pull request (PR) is a proposal to merge a set of code changes into a specific branch. The Pull Request Number links development activities, such as code pushes and reviews, back to the primary development item or issue.

This ID is crucial for tracking the code integration and review sub-process within the broader development lifecycle. It allows for detailed analysis of the code review process, including review times, rework cycles identified during review, and merge rates. It connects the planning phase (issue) with the implementation phase (PR).

Why it matters

Links issues to the specific code changes and review processes, enabling detailed analysis of the code review cycle and its impact on overall delivery time.

Where to get

Available as the 'number' field within the 'pull_request' object in many GitHub API responses, or as the main identifier from the Pull Requests API.

Examples
12345678910
Review State
ReviewState
The outcome of a code review on a pull request, such as 'Approved' or 'Changes Requested'.
Description

This attribute captures the decision made by a reviewer. Common states include 'APPROVED', indicating the code is ready to be merged, and 'CHANGES_REQUESTED', indicating that rework is required. Other states might include 'COMMENTED' or 'PENDING'.

This is a critical attribute for analyzing rework and quality. A high frequency of 'CHANGES_REQUESTED' events can indicate issues with initial code quality or unclear requirements. It directly supports the 'Rework and Regression Loops' dashboard by identifying when a development item is sent back for modification.

Why it matters

Directly indicates rework loops and quality gates within the code review process, helping to pinpoint sources of inefficiency and quality issues.

Where to get

Available as the 'state' field within a pull request review object from the GitHub API. For example, in a 'PullRequestReviewEvent' payload.

Examples
APPROVEDCHANGES_REQUESTEDCOMMENTED
Reviewer
Reviewer
The user requested to perform a code review on a pull request.
Description

A reviewer is a developer or team member assigned to inspect code changes in a pull request for quality, correctness, and adherence to standards. A pull request can have multiple reviewers.

This attribute is essential for analyzing the code review process. It helps identify bottlenecks related to specific reviewers, understand review workload distribution, and measure the time it takes for reviewers to respond to requests. It is a key component for calculating the 'Average Code Review Cycle Time' KPI.

Why it matters

Identifies the individuals involved in the quality assurance process, enabling analysis of review workloads, delays, and the overall efficiency of code reviews.

Where to get

Available in the 'requested_reviewers' array or the 'user' object of a pull request review event from the GitHub API.

Examples
alex.chenmaria.garciasenior-dev-team
Source System
SourceSystem
The system from which the development process data was extracted.
Description

This attribute identifies the origin of the event data. For this process, the value would consistently be 'GitHub'. In a more complex environment where development activities span multiple systems (e.g., Jira for planning, GitHub for code, Jenkins for deployment), this field is used to distinguish the source of each event.

In analysis, it helps in tracing data back to its origin for validation and troubleshooting. It also allows for analyzing processes that cross different platforms, providing a clear context for each activity.

Why it matters

Identifies the data's origin, which is essential for data validation and for analyzing processes that may span multiple integrated systems.

Where to get

This is typically a static value added during the data extraction, transformation, and loading (ETL) process to label the source of the records.

Examples
GitHubGitHub Enterprise
Required Recommended Optional

Software Development Lifecycle Activities

These are the key process steps and milestones to capture in your event log for accurate process discovery and bottleneck identification.
6 Recommended 7 Optional
Activity Description
CI Checks Passed
Represents the successful completion of automated checks, such as builds, unit tests, or static analysis, run against the code in a pull request. This event is inferred from the status of checks reported by systems like GitHub Actions.
Why it matters

This automated quality gate is crucial for ensuring code stability. Failures or long run times can be significant bottlenecks in the delivery pipeline.

Where to get

Inferred from the GitHub Checks API or Statuses API. A check run or status update reports a 'success' or 'completed' with a 'success' conclusion.

Capture

Monitor the Checks API for a 'success' conclusion on the relevant check suites.

Event type inferred
Issue Closed
The development item is considered complete, and the corresponding issue is formally closed. This can happen automatically when a linked pull request is merged or be performed manually by a team member.
Why it matters

This activity serves as the definitive end of the process for a development item. It is critical for calculating end-to-end cycle times.

Where to get

This is an explicit event captured from the GitHub Issues API event stream. The event type is 'closed'.

Capture

Listen for the 'closed' event on an issue via webhooks or API polling.

Event type explicit
Issue Created
Marks the beginning of a development item's lifecycle, representing the formal creation of a task, bug, or feature request. This event is captured explicitly when a user creates a new issue in a GitHub repository.
Why it matters

This is the primary start activity for the process, essential for measuring the total development cycle time and understanding the initial sources of work.

Where to get

This is an explicit event captured from the GitHub Issues API event stream. The event type is typically 'opened' for a given issue number.

Capture

Listen for the 'opened' event on an issue via webhooks or API polling.

Event type explicit
Pull Request Approved
A reviewer has formally approved the changes in a pull request, indicating it meets quality and functional standards. This is captured when a reviewer submits their review with an 'approve' status.
Why it matters

This is a key quality gate and a major milestone before merging. The time taken to reach this state from PR creation is a critical KPI for review process efficiency.

Where to get

Captured from the GitHub Pull Request API or webhooks when a review is submitted with the state 'APPROVED'.

Capture

Filter pull request review submission events for the state 'APPROVED'.

Event type explicit
Pull Request Merged
The approved code changes from the pull request are officially integrated into the target branch, such as main or develop. This is an explicit, final action on a pull request that incorporates the new code.
Why it matters

This is a critical milestone representing the completion of development and review. For many teams, this is the final step before automated deployment.

Where to get

Captured from the GitHub Pull Request API event stream or webhooks. The event action is 'closed' and the 'merged' attribute of the pull request payload is true.

Capture

Listen for the 'closed' action on a pull request and check if the 'merged' flag is true.

Event type explicit
Pull Request Opened
Signifies that an initial block of code is ready for review and integration. A developer creates a pull request (PR) to propose changes from their feature branch to a main branch. This is an explicit event in GitHub.
Why it matters

This is a critical milestone that marks the end of the initial development phase and the beginning of the review and integration pipeline. It is key to analyzing development and review cycle times separately.

Where to get

Captured from the GitHub Pull Request API event stream or webhooks. The event action is 'opened'.

Capture

Listen for the 'opened' action for a pull request via webhooks or API polling.

Event type explicit
Branch Created
Represents the start of active development work for an issue, where a developer creates a new branch from the main codebase. This is an explicit event captured when a new branch is pushed to the repository, often containing the issue number in its name.
Why it matters

Indicates the transition from planning to active coding. Measuring the time between issue creation and this event helps analyze developer pickup time and initial backlog delays.

Where to get

Captured via the GitHub Git API or webhooks listening for 'create' events of type 'branch'. It's often necessary to link the branch name to an issue via naming conventions, like 'feature/issue-123'.

Capture

Parse 'create' webhook events for new branches and associate them with an issue.

Event type explicit
Changes Requested in Review
A reviewer has completed their code review and determined that modifications are necessary before the pull request can be approved. The reviewer formally submits their review with a 'request_changes' status.
Why it matters

This event explicitly signals a rework loop. Analyzing its frequency helps pinpoint quality issues, unclear requirements, or areas for developer training.

Where to get

Captured from the GitHub Pull Request API or webhooks when a review is submitted with the state 'CHANGES_REQUESTED'.

Capture

Filter pull request review submission events for the state 'CHANGES_REQUESTED'.

Event type explicit
CI Checks Failed
Represents the failure of an automated check, such as a build error or failed unit test, run against the code in a pull request. This is inferred from a failure status reported by a system like GitHub Actions.
Why it matters

This activity highlights technical quality issues that require developer intervention, creating a rework loop. Analyzing failure frequency can guide improvements in local testing or code quality.

Where to get

Inferred from the GitHub Checks API or Statuses API. A check run or status update reports a 'failure' or 'completed' with a 'failure' conclusion.

Capture

Monitor the Checks API for a 'failure' conclusion on the relevant check suites.

Event type inferred
Code Pushed to PR
Represents an update to the code submitted for review, either as part of the initial PR or in response to review feedback. This event is captured every time a new commit is pushed to the branch associated with an open pull request.
Why it matters

Tracking these events is crucial for identifying rework loops. Multiple pushes after a review indicates that changes were required, affecting the overall cycle time.

Where to get

This is an explicit event in the pull request timeline, often labeled as a commit being added. It can be captured from the 'push' webhook or by monitoring the commits associated with a PR.

Capture

Track 'push' events on a branch associated with an open pull request.

Event type explicit
Deployment Succeeded
The code changes have been successfully deployed to a specific environment, such as staging or production. This event is typically captured via the GitHub Deployments API, often triggered by a GitHub Action after a merge.
Why it matters

Marks the transition of code from the repository to a live environment. Tracking this is essential for measuring the full lead time from idea to production.

Where to get

Captured via the Deployments API. An external service or GitHub Action creates a deployment and then updates its status to 'success'.

Capture

Monitor deployment status events via webhooks for a state of 'success'.

Event type inferred
Issue Reopened
A previously closed issue is reactivated, typically because the fix was insufficient or a regression was found. This is an explicit event that re-starts the lifecycle for the development item.
Why it matters

This signals a significant rework loop, indicating a potential 'production defect escape' or incomplete fix. Tracking its frequency is a key measure of overall software quality.

Where to get

This is an explicit event captured from the GitHub Issues API event stream. The event type is 'reopened'.

Capture

Listen for the 'reopened' event on an issue via webhooks or API polling.

Event type explicit
Review Requested
The author of a pull request formally asks specific team members or teams to review their code. This is an explicit action within the GitHub UI or API that triggers notifications to the requested reviewers.
Why it matters

This activity marks the official start of the handoff to the code review process. The time between this and a review submission helps measure reviewer responsiveness and potential bottlenecks.

Where to get

Captured from the GitHub Pull Request API event stream or webhooks. The event action is 'review_requested'.

Capture

Listen for the 'review_requested' action for a pull request.

Event type explicit
Recommended Optional

Extraction Guides

How to get your data from GitHub