The GitLab.com risk of having “Inactive project deletion” disabled and “Delayed project deletion” enabled
Posted by jpluimers on 2026/05/27
After the 2022 GitLab.com backlash* to auto-delete “inactive” (for whichever metric of “inactive”) repositories of free users, I thought they would have multiple checks in place to prevent that from happening.
TL;DR: of two possible checks to prevent this, only one is in place.
This means that if by accident one of those checks stops working, all inactive repositories will be be deleted after a 7 day retention period. Which is very short, especially when you miss the email about it (for instance because of holiday or health reasons).
That bad!
How/why I found out
So a while after recovering from most of my cancer-treatment side-effects, I decided to check what would happen to my lesser updated repositories and found”
- [Wayback/Archive] Project settings | GitLab: delayed project deletion which points to [Wayback/Archive] Control access and visibility | GitLab: delayed project deletion which in turn is part of a section called “Deletion protection” of which I quote a few bits further below
- [Wayback/Archive] GitLab.com settings | GitLab: delayed project deletion which shows there are two checks that can be in place:
Delayed project deletion
PREMIUMSAASTop-level groups created after August 12, 2021 have delayed project deletion enabled by default. Projects are permanently deleted after a seven-day delay.If you are on:- Premium tier and above, you can disable this by changing the group setting.
- Free tier, you cannot disable this setting or restore projects.
Inactive project deletion
Inactive project deletion is disabled on GitLab.com.I will quote from the last link below as well.
So of the two checks, only one is preventing project deletion!
* Backlash
- [Wayback/Archive] GitLab U-turns on deleting dormant projects after backlash • The Register
- [Wayback/Archive] GitLab Backtracks On Deleting Inactive Projects by Free Users
Both via [Wayback/Archive] gitlab deletes inactive projects – Google Search.
GitLab “Deletion protection” quotes
I underlined the most important bits for GitLab.com for Free Users from [Wayback/Archive] Control access and visibility | GitLab: deletion protection:
Retention period
Changed in GitLab 15.1.
Groups and projects remain restorable within a defined retention period. By default this is 7 days but it can be changed. Setting the retention period to
0means that groups and project are removed immediately and cannot be restored.In GitLab 15.1 and later, the retention period must be between
1and90. If the retention period was0before the 15.1 update, then it gets automatically changed to1while also disabling deletion protection the next time any application setting is changed.Delayed project deletion
User interface changed in GitLab 15.1.
Administrators can enable delayed project deletion by default for newly-created groups. Group owners can choose to disable this. When disabled, existing groups retain their existing setting. When enabled deleted groups remain restorable within a retention period.
To configure delayed project deletion:
- Sign in to GitLab as a user with administrator access.
- On the top bar, select Main menu > Admin.
- On the left sidebar, select Settings > General.
- Expand the Visibility and access controls section.
- Scroll to:
- (GitLab 15.11 and later with
always_perform_delayed_deletionfeature flag enabled) Deletion protection and set the retention period to a value between1and90.- (GitLab 15.1 and later) Deletion protection and select keep deleted groups and projects, and select a retention period.
- (GitLab 15.0 and earlier) Default delayed project protection and select Enable delayed project deletion by default for newly-created groups. Then set a retention period in Default deletion delay.
- Select Save changes.
Deletion protection is not available for projects only (without being also being enabled for groups).
In GitLab 15.1, and later this setting is enforced on groups when disabled and it cannot be overridden.
Delayed group deletion
User interface introduced in GitLab 15.1.
Groups remain restorable if the retention period is
1or more days.In GitLab 15.1 and later, delayed group deletion can be enabled by setting Deletion projection to Keep deleted. In GitLab 15.11 and later with the
always_perform_delayed_deletionfeature flag enabled:
- The Keep deleted option is removed.
- Delayed group deletion is the default.
Inactive project deletion quotes
Like above, but now from [Wayback/Archive] Inactive project deletion | GitLab:
Administrators of large GitLab instances can find that over time, projects become inactive and are no longer used. These projects take up unnecessary disk space.
With inactive project deletion, you can identify these projects, warn the maintainers ahead of time, and then delete the projects if they remain inactive. When an inactive project is deleted, the action generates an audit event that it was performed by the @GitLab-Admin-Bot.
For the default setting on GitLab.com, see the GitLab.com settings page.
…
Determine when a project was last active
You can view a project’s activities and determine when the project was last active in the following ways:
- Go to the activity page for the project and view the date of the latest event.
- View the
last_activity_atattribute for the project using the Projects API.- List the visible events for the project using the Events API. View the
created_atattribute of the latest event.
–jeroen






Leave a comment