The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 1,839 other subscribers

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”

  1. [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
  2. [Wayback/Archive] GitLab.com settings | GitLab: delayed project deletion which shows there are two checks that can be in place:

    Delayed project deletion

    PREMIUM
    SAAS
    Top-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

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 0 means that groups and project are removed immediately and cannot be restored.

In GitLab 15.1 and later, the retention period must be between 1 and 90. If the retention period was 0 before the 15.1 update, then it gets automatically changed to 1 while 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:

  1. Sign in to GitLab as a user with administrator access.
  2. On the top bar, select Main menu > Admin.
  3. On the left sidebar, select Settings > General.
  4. Expand the Visibility and access controls section.
  5. Scroll to:
    • (GitLab 15.11 and later with always_perform_delayed_deletion feature flag enabled) Deletion protection and set the retention period to a value between 1 and 90.
    • (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.
  6. 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 1 or 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_deletion feature 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_at attribute for the project using the Projects API.
  • List the visible events for the project using the Events API. View the created_at attribute of the latest event.

–jeroen

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.