2019-10-12 21:52:04 +05:30
---
type: howto
2020-06-23 00:09:42 +05:30
stage: Manage
group: Access
2021-02-22 17:27:13 +05:30
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
2019-10-12 21:52:04 +05:30
---
# Deleting a User account
Users can be deleted from a GitLab instance, either by:
- The user themselves.
- An administrator.
2017-08-17 22:00:37 +05:30
2021-02-22 17:27:13 +05:30
NOTE:
2018-12-05 23:21:45 +05:30
Deleting a user will delete all projects in that user namespace.
2019-10-12 21:52:04 +05:30
## As a user
2021-03-11 19:13:27 +05:30
As a user, to delete your own account:
2019-10-12 21:52:04 +05:30
2021-03-11 19:13:27 +05:30
1. In the top-right corner, select your avatar.
1. Select **Edit profile** .
1. In the left sidebar, select **Account** .
1. Select **Delete account** .
2019-10-12 21:52:04 +05:30
## As an administrator
2021-03-11 19:13:27 +05:30
As an administrator, to delete a user account:
2019-10-12 21:52:04 +05:30
2021-03-11 19:13:27 +05:30
1. Go to **Admin Area > Overview > Users** .
1. Select a user.
1. Under the **Account** tab, select:
- **Delete user** to delete only the user but maintain their
2019-10-12 21:52:04 +05:30
[associated records ](#associated-records ).
- **Delete user and contributions** to delete the user and
their associated records.
2021-02-22 17:27:13 +05:30
WARNING:
2020-07-28 23:09:34 +05:30
Using the **Delete user and contributions** option may result
2020-04-22 19:07:51 +05:30
in removing more data than intended. Please see [associated records ](#associated-records )
below for additional details.
2017-08-17 22:00:37 +05:30
## Associated Records
2020-04-22 19:07:51 +05:30
> - Introduced for issues in [GitLab 9.0](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/7393).
> - Introduced for merge requests, award emoji, notes, and abuse reports in [GitLab 9.1](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/10467).
> - Hard deletion from abuse reports and spam logs was introduced in [GitLab 9.1](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/10273), and from the API in [GitLab 9.3](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/11853).
There are two options for deleting users:
2017-08-17 22:00:37 +05:30
2020-04-22 19:07:51 +05:30
- **Delete user**
- **Delete user and contributions**
When using the **Delete user** option, not all associated records are deleted with the user.
2019-07-31 22:56:46 +05:30
Here's a list of things that will **not** be deleted:
2017-08-17 22:00:37 +05:30
2019-10-12 21:52:04 +05:30
- Issues that the user created.
- Merge requests that the user created.
- Notes that the user created.
- Abuse reports that the user reported.
- Award emoji that the user created.
2017-08-17 22:00:37 +05:30
2017-09-10 17:25:29 +05:30
Instead of being deleted, these records will be moved to a system-wide
2019-10-12 21:52:04 +05:30
user with the username "Ghost User", whose sole purpose is to act as a container
for such records. Any commits made by a deleted user will still display the
username of the original user.
2017-08-17 22:00:37 +05:30
2020-04-22 19:07:51 +05:30
When using the **Delete user and contributions** option, **all** associated records
are removed. This includes all of the items mentioned above including issues,
merge requests, notes/comments, and more. Consider
[blocking a user ](../../admin_area/blocking_unblocking_users.md )
or using the **Delete user** option instead.
2019-10-12 21:52:04 +05:30
When a user is deleted from an [abuse report ](../../admin_area/abuse_reports.md )
or spam log, these associated
2017-09-10 17:25:29 +05:30
records are not ghosted and will be removed, along with any groups the user
2019-10-12 21:52:04 +05:30
is a sole owner of. Administrators can also request this behavior when
2017-09-10 17:25:29 +05:30
deleting users from the [API ](../../../api/users.md#user-deletion ) or the
2019-10-12 21:52:04 +05:30
Admin Area.
<!-- ## Troubleshooting
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
one might have when setting this up, or when something is changed, or on upgrading, it's
important to describe those, too. Think of things that may go wrong and include them here.
This is important to minimize requests for support, and to avoid doc comments with
questions that you know someone might ask.
2017-08-17 22:00:37 +05:30
2019-10-12 21:52:04 +05:30
Each scenario can be a third-level heading, e.g. `### Getting error message X` .
If you have none to add when creating a doc, leave this section in place
but commented out to help encourage others to add to it in the future. -->