2019-09-04 21:01:54 +05:30
---
2021-01-29 00:20:46 +05:30
stage: none
group: unassigned
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-09-04 21:01:54 +05:30
type: reference
---
2019-12-04 20:38:33 +05:30
# Usage statistics **(CORE ONLY)**
2017-08-17 22:00:37 +05:30
2021-02-22 17:27:13 +05:30
GitLab Inc. periodically collects information about your instance in order
2017-08-17 22:00:37 +05:30
to perform various actions.
2020-03-13 15:44:24 +05:30
All statistics are opt-out. You can enable/disable them in the
**Admin Area > Settings > Metrics and profiling** section **Usage statistics** .
2017-08-17 22:00:37 +05:30
2020-04-22 19:07:51 +05:30
## Network configuration
2020-04-08 14:13:33 +05:30
Allow network traffic from your GitLab instance to IP address `104.196.17.203:443` , to send
usage statistics to GitLab Inc.
2020-04-22 19:07:51 +05:30
If your GitLab instance is behind a proxy, set the appropriate [proxy configuration variables ](https://docs.gitlab.com/omnibus/settings/environment-variables.html ).
2020-03-13 15:44:24 +05:30
## Version Check **(CORE ONLY)**
2017-08-17 22:00:37 +05:30
2021-02-22 17:27:13 +05:30
If enabled, version check informs you if a new version is available and the
2018-03-27 19:54:05 +05:30
importance of it through a status. This is shown on the help page (i.e. `/help` )
for all signed in users, and on the admin pages. The statuses are:
2017-08-17 22:00:37 +05:30
2019-03-02 22:35:43 +05:30
- Green: You are running the latest version of GitLab.
- Orange: An updated version of GitLab is available.
- Red: The version of GitLab you are running is vulnerable. You should install
2018-03-27 19:54:05 +05:30
the latest version with security fixes as soon as possible.
2017-08-17 22:00:37 +05:30
2018-03-27 19:54:05 +05:30
![Orange version check example ](img/update-available.png )
2017-08-17 22:00:37 +05:30
2018-03-27 19:54:05 +05:30
GitLab Inc. collects your instance's version and hostname (through the HTTP
referer) as part of the version check. No other information is collected.
2017-08-17 22:00:37 +05:30
2018-03-27 19:54:05 +05:30
This information is used, among other things, to identify to which versions
2021-02-22 17:27:13 +05:30
patches must be backported, making sure active GitLab instances remain
2018-03-27 19:54:05 +05:30
secure.
2021-02-22 17:27:13 +05:30
If you disable version check, this information isn't collected. Enable or
2020-03-13 15:44:24 +05:30
disable the version check in **Admin Area > Settings > Metrics and profiling > Usage statistics** .
2017-08-17 22:00:37 +05:30
2020-03-13 15:44:24 +05:30
### Request flow example
The following example shows a basic request/response flow between the self-managed GitLab instance
and the GitLab Version Application:
```mermaid
sequenceDiagram
participant GitLab instance
participant Version Application
GitLab instance->>Version Application: Is there a version update?
loop Version Check
Version Application->>Version Application: Record version info
end
Version Application->>GitLab instance: Response (PNG/SVG)
```
## Usage Ping **(CORE ONLY)**
2017-08-17 22:00:37 +05:30
2021-01-03 14:25:43 +05:30
See [Usage Ping guide ](../../../development/product_analytics/usage_ping.md ).
2017-08-17 22:00:37 +05:30
2020-11-24 15:15:51 +05:30
## Instance-level statistics **(CORE ONLY)**
2018-11-18 11:00:15 +05:30
2021-02-22 17:27:13 +05:30
After usage ping is enabled, GitLab gathers data from other instances and
can show [usage statistics ](../analytics/index.md )
2020-11-24 15:15:51 +05:30
of your instance to your admins in **Admin Area > Analytics** .
2018-11-18 11:00:15 +05:30
2019-09-04 21:01:54 +05:30
<!-- ## 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.
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. -->