Skip to main content

Issues and PRs > Created at

Tom Williams avatar
Written by Tom Williams
Updated over a week ago

Dataset: Issues & Pull Requests

Entity: Pull Requests, Issues

Field ID: created_at

Type: Datetime

Description: The datetime at which the pull request or issue was created.

Source: App

Transformation logic: N/A

From:

Github (PRs, Issues)

created_at

Gitlab (PRs, Issues)

created_at

Bitbucket (PRs)

created_on

Azure DevOps (PRs, Issues)

creationDate

JIRA (Issues)

created

ClickUp (Issues)

date_created

Trello (Issues)

created_at

Reporting Use Cases

The Created At field is a cornerstone for nearly all time-based analysis, marking the exact moment an issue or pull request was opened. It serves as the "start" point for the item's entire lifecycle and is fundamental for tracking workload, calculating performance metrics, and analyzing trends.

  • Reporting and Trend Analysis: Its most common use is as a dimension in time-series charts to track the volume of incoming work.

    • By grouping data with a dimension like YEAR_MONTH(created_at) and using COUNT() as a metric, you can build a line chart that visualizes the number of new issues or pull requests created each month. This is essential for understanding team workload and for capacity planning.

    • You can compare the volume of created items to closed items over the same period to monitor whether your backlog is growing or shrinking.

  • Calculating Lead Times and Item Age: As the definitive start time, Created At is the baseline for measuring how long different phases of the development process take.

    • Lead Time for Changes: This critical DORA metric measures the total time from creation to completion and is calculated with the formula (closed_at - created_at) / DAY().

    • Time to Triage: You can measure how quickly new issues are picked up by calculating the time from creation to first assignment: (assigned_at - created_at) / HOUR().

    • Age of Open Items: For items that are still open, you can calculate their current age with (NOW() - created_at) / DAY(), which is crucial for identifying and prioritizing stale or forgotten work.

  • Filtering by Time: You can scope any widget to a specific creation period, which is standard practice for building relevant, time-bound reports.

    • To analyze recent activity, you can apply a filter like Created At in the previous 12 months.

    • To find potentially outdated items in your backlog, you could filter for all open issues where Created At before 2 years ago.

Did this answer your question?