1. You are here:
2. Handbook
3. Support Team Handbook
4. Support Workflows
5. Log and audit requests

On this page

• Log requests for GitLab.com
  • Who can make a request
    • Paid Subscriptions
    • Free Users
  • What we can provide
  • What we cannot provide
  • Sending logs and other PII
  • Examples
    • Example 1: Who accessed a specific repo
    • Example 2: IP block
    • Example 3: GitLab requests action due to high load

Log requests for GitLab.com

Users often ask for access to GitLab.com logs, typically, due to IP blocks, a possible security issue, or for internal auditing purposes.

Always include a link to the log as an internal note, with additional information if needed.

If required, you can escalate the ticket/issue by following our escalation process.

A standard response is available in ZenDesk as a macro Support::SaaS::Audit logs access request.

Log requests beyond a summary (similar to the examples below) or where logs are not readily available on Kibana should be handled according to the process outlined in the handbook page dedicated to providing assistance to GitLab.com customers during customer-based security incidents.

Who can make a request

Paid Subscriptions

Requester must be a Group Owner of a pre-existing paid namespace.

• Must verify that this is who is making the request and should be in alignment with support for Enterprise Users

NOTE: A user cannot upgrade to a paid subscription to gain access to logging requests.

Free Users

Free users should reference GitLab.com rate limits documentation. Support will provide information when GitLab initiates contact due to an incident.

What we can provide

We can provide the following information:

• Information found in the Audit Events Features
• Information about who has accessed the account/projects that the customers owns. This can include:
  • number of users
  • number of times accessed
  • number of unique IPs
  • range of timestamp of occurrence
  • project path
• Provide the above excluding a known list. For example, number of IP addresses not originating from a user's "work office".

What we cannot provide

We cannot provide the following information:

• Information about accounts or projects that the requester does not own.
• Any information considered Personally Identifiable Information (PII) that is not about the requester. Also consider the data covered under GDPR.
• Any information that would disclose GitLab confidential information or processes.

Sending logs and other PII

Any PII information that is pulled, such as a log request, needs to be delivered compressed and password protected to the requestor with the following guidelines:

• The password should be a random string of at least 10+ characters including numbers, lower and upper case letters.
• The password protected file should be attached to the ZenDesk ticket, and the password needs to be sent separately through your email account directly to the customer's email address.
• Once the customer had successfully received and opened the files you should delete the pulled data from your computer and the email from your mailbox.

In case you need to share the data pull results internally, such as in an internal issue, upload the files to Google Drive, such as the Support Ticket Attachments folder (internal).

Examples

The following are examples to provide a better idea of what responses we can provide.

Example 1: Who accessed a specific repo

A customer, who had accidentally set their project to the incorrect visibility setting, wanted to know if anyone outside the company accessed their project. Here is a modified excerpt of the response:

Excluding users who have the company email domain, 2 users viewed the main project page a total of 4 times between 20:06 and 20:10 UTC 2019-08-15. However, I can confirm that all 4 instances originated from one of the IP addresses you provided as being from your office.

From ticket: 129594

Example 2: IP block

User writes in to say their entire team is getting blocked and they want to know the source. When the user writing in has access to the projects in question, we can provide the specific path(s).

It appears that the majority of requests that returned 401, which likely caused the temporary block, involved /project/path.

Example ticket: 132652

Also see "Identifying the Cause of IP Blocks on GitLab.com".

Example 3: GitLab requests action due to high load

GitLab reached out to the owners of a project that was causing concern for the production team, who asked Support to reach out. The user wanted to know where the requests were originating from.

There are 3 different IPs showing in our logs, 2 of which are based in CountryA and 1 in CountryB (please note these locations may not be accurate as they are based purely on geolocation web searches). They also all have the same user agent.

Example ticket: 130153