Updating Retention Period for `last_activity_at` Values on the Copilot User Management API to 90 Days

Summary

Starting Tuesday, February 18th, 2025, we will be updating our retention policy so that the last_activity_at field will only be actively stored by GitHub for 90 days. Previously, this contents of this field were retained indefinitely.

What’s Changing

• Old Policy: Unlimited retention of the last_activity_at value.
• New Policy: A rolling 90-day retention period. If your data’s last_activity_at exceeds 90 days, its value will be set to nil.

Expected Impact

The vast majority of our users will see little or no impact because the last_activity_at field should always display the most recent activity date.

Only users with no new activity within a 90-day window will have their last_activity_at value replaced by nil. In practice this means that on the changeover date, users whose last activity with Copilot took place prior to 11/20/2024 will have the value for their last_activity_at replaced on a rolling-forward basis.

Detail

Clarifying the behavior of last_activity_at in the context of the current changes:

1. Assigning a Seat: When you assign a seat to a user, the last_activity value for that seat will be nil until the user interacts with it for the first time. This is true even if the user had previous activity from a different seat assignment in another organization.

2. Removing a Seat: When you remove a seat from a user, the last_activity data for that user is set to nil in the revoking org. Their data is unaffected for other admins who have granted that user a seat in other orgs, when pulled for those orgs.

3. Reassigning a User to Seat: If you remove a seat from a user and later assign a new seat to the same user, the last_activity value for the new seat will again be nil until the user’s next interaction, regardless of whether the seat was previously assigned to them.

4. Deleting a User: If you delete a user, all associated last_activity data for that user is immediately deleted.

5. Determining Dormancy: When retrieving activity data for a seat, you can use the created_at and last_activity values to determine dormancy. For example, if created_at is more than 30 days ago and last_activity is either more than 30 days ago or nil, the seat may considered dormant.

6. Activity Data for Assigned Seats: When retrieving last_activity data for assigned seats, you will receive a nil value if the assignee’s most recent activity record is older than 90 days.

Note: Behavior of the data will remain consistent with the Activity Report, available in Admin UI.

Why We’re Making This Change

Our external data surfaces must be quality first. Retaining data of this volume for multi-year retention periods increases storage and backup overhead significantly, as well as the cost and complexity of quality checks. A time-bound retention policy allows us to maintain efficiency while still offering relevant, up-to-date information. This will allow us to further improve the resilience of the data that is returned by the endpoint, while limiting the impact only to very old records.

Next Steps

You don’t need to take any action if you rely on the last_activity_at field for current activity records.

However, if for any reason you have workflows or reports that depend on usage dates for active seats that have been dormant for 90 or more days, please be aware that these values will become nil for records older than 90 days, for dates on or before November 20th, 2024, as of Tuesday, February 18th, 2025. While exceptionally rare, we encourage you to store API responses for cases where this will become problematic.