Dataset: Activity Events
Entity: Activity Events
Field ID: updated_at
Type: Datetime
Description: The datetime at which the event was last updated. This field is currently always equal to Created at. It is provided to keep datasets consistent with each other.
Source: Applications support the following events
Github:
CREATED,CLOSED,REOPENED,MERGED,REVIEWER_ASSIGNED,REVIEWER_UNASSIGNED,USER_ASSIGNED,USER_UNASSIGNEDGitLab:
CREATED,CLOSED,REOPENED,MERGED,REVIEWER_ASSIGNED,REVIEWER_UNASSIGNED,USER_ASSIGNED,USER_UNASSIGNED,WORK_LOGGEDBitbucket:
CREATED,CLOSED,MERGED,REVIEWER_ASSIGNED,REVIEWER_UNASSIGNEDAzure DevOps:
CREATED,CLOSED,MERGED,REVIEWER_ASSIGNED,REVIEWER_UNASSIGNEDJira:
CREATED,CLOSED,REOPENED,USER_ASSIGNED,USER_UNASSIGNED,WORK_LOGGED,WORKFLOW_STATUS_UPDATEDClickUp:
CREATED,CLOSED. ClickUp does not expose an events API. Keypup generates these two events based on the issue timestamps (date_created&date_closed)Trello:
CREATED,CLOSED,REOPENED,USER_ASSIGNED,USER_UNASSIGNED,WORKFLOW_STATUS_UPDATED
Transformation logic: N/A
From: |
|
Github (Timeline Items) |
|
Gitlab (Discussions, State Events) |
|
Bitbucket (Activity) |
|
Azure DevOps (PR Threads) |
|
Jira (Changelog, Worklog) |
|
ClickUp (Issue timestamps) |
|
Trello (Actions) |
|
Reporting Use Cases
The Updated At field from the Activity Events dataset is the timestamp is equal to the Created At timestamp, since events are immutable. Similar use cases apply.
Filtering for Time-Based Analysis: Its most common use is to scope your analysis to a specific time period.
To create an activity feed for a daily stand-up, you can use a filter like
Updated At in the previous 24 hours.To review all the workflow changes that happened last quarter, you would filter where
Updated At in the previous quarter.
Reporting on Activity Volume: When used as a dimension, this field allows you to visualize the frequency and trends of different activities over time.
You can create a line chart with a dimension like
YEAR_MONTH(updated_at)and a metric likeCOUNT_IF(action == "MERGED")to track the number of merges per month.
Enabling Historical State Reconstruction: This is the most powerful use case for this field. It provides the chronological order needed to build cumulative charts that reconstruct the state of your system at any point in the past.
To build a chart showing the total number of open issues over time, you need a time-series dimension like
YEAR_MONTH(updated_at)and a cumulative metric that adds or subtracts based on the event type:SUM_CUMULATIVE(IF(CONTAINS(["CREATED", "REOPENED"], action), 1, -1)). This calculation is entirely dependent on theupdated_atfield to provide the correct sequence of events.