Reporting Anonymised Statistics

When generating your Synapse configuration file, you are asked whether you would like to report anonymised statistics to Matrix.org. These statistics provide the foundation a glimpse into the number of Synapse homeservers participating in the network, as well as statistics such as the number of rooms being created and messages being sent. This feature is sometimes affectionately called "phone-home" stats. Reporting is optional and the reporting endpoint can be configured, in case you would like to instead report statistics from a set of homeservers to your own infrastructure.

This documentation aims to define the statistics available and the homeserver configuration options that exist to tweak it.

Available Statistics

The following statistics are sent to the configured reporting endpoint:

Statistic NameTypeDescription
memory_rssintThe memory usage of the process (in kilobytes on Unix-based systems, bytes on MacOS).
cpu_averageintCPU time in % of a single core (not % of all cores).
homeserverstringThe homeserver's server name.
server_contextstringAn arbitrary string used to group statistics from a set of homeservers.
timestampintThe current time, represented as the number of seconds since the epoch.
uptime_secondsintThe number of seconds since the homeserver was last started.
python_versionstringThe Python version number in use (e.g "3.7.1"). Taken from sys.version_info.
total_usersintThe number of registered users on the homeserver.
total_nonbridged_usersintThe number of users, excluding those created by an Application Service.
daily_user_type_nativeintThe number of native users created in the last 24 hours.
daily_user_type_guestintThe number of guest users created in the last 24 hours.
daily_user_type_bridgedintThe number of users created by Application Services in the last 24 hours.
total_room_countintThe total number of rooms present on the homeserver.
daily_active_usersintThe number of unique users1 that have used the homeserver in the last 24 hours.
monthly_active_usersintThe number of unique users1 that have used the homeserver in the last 30 days.
daily_active_roomsintThe number of rooms that have had a (state) event with the type m.room.message sent in them in the last 24 hours.
daily_active_e2ee_roomsintThe number of rooms that have had a (state) event with the type m.room.encrypted sent in them in the last 24 hours.
daily_messagesintThe number of (state) events with the type m.room.message seen in the last 24 hours.
daily_e2ee_messagesintThe number of (state) events with the type m.room.encrypted seen in the last 24 hours.
daily_sent_messagesintThe number of (state) events sent by a local user with the type m.room.message seen in the last 24 hours.
daily_sent_e2ee_messagesintThe number of (state) events sent by a local user with the type m.room.encrypted seen in the last 24 hours.
r30_users_allintThe number of 30 day retained users, defined as users who have created their accounts more than 30 days ago, where they were last seen at most 30 days ago and where those two timestamps are over 30 days apart. Includes clients that do not fit into the below r30 client types.
r30_users_androidintThe number of 30 day retained users, as defined above. Filtered only to clients with "Android" in the user agent string.
r30_users_iosintThe number of 30 day retained users, as defined above. Filtered only to clients with "iOS" in the user agent string.
r30_users_electronintThe number of 30 day retained users, as defined above. Filtered only to clients with "Electron" in the user agent string.
r30_users_webintThe number of 30 day retained users, as defined above. Filtered only to clients with "Mozilla" or "Gecko" in the user agent string.
r30v2_users_allintThe number of 30 day retained users, with a revised algorithm. Defined as users that appear more than once in the past 60 days, and have more than 30 days between the most and least recent appearances in the past 60 days. Includes clients that do not fit into the below r30 client types.
r30v2_users_androidintThe number of 30 day retained users, as defined above. Filtered only to clients with ("riot" or "element") and "android" (case-insensitive) in the user agent string.
r30v2_users_iosintThe number of 30 day retained users, as defined above. Filtered only to clients with ("riot" or "element") and "ios" (case-insensitive) in the user agent string.
r30v2_users_electronintThe number of 30 day retained users, as defined above. Filtered only to clients with ("riot" or "element") and "electron" (case-insensitive) in the user agent string.
r30v2_users_webintThe number of 30 day retained users, as defined above. Filtered only to clients with "mozilla" or "gecko" (case-insensitive) in the user agent string.
cache_factorintThe configured global factor value for caching.
event_cache_sizeintThe configured event_cache_size value for caching.
database_enginestringThe database engine that is in use. Either "psycopg2" meaning PostgreSQL is in use, or "sqlite3" for SQLite3.
database_server_versionstringThe version of the database server. Examples being "10.10" for PostgreSQL server version 10.0, and "3.38.5" for SQLite 3.38.5 installed on the system.
log_levelstringThe log level in use. Examples are "INFO", "WARNING", "ERROR", "DEBUG", etc.
1

Native matrix users and guests are always counted. If the track_puppeted_user_ips option is set to true, "puppeted" users (users that an Application Service have performed an action on behalf of) will also be counted. Note that an Application Service can "puppet" any user in their user namespace, not only users that the Application Service has created. If this happens, the Application Service will additionally be counted as a user (irrespective of track_puppeted_user_ips).

Using a Custom Statistics Collection Server

If statistics reporting is enabled, the endpoint that Synapse sends metrics to is configured by the report_stats_endpoint config option. By default, statistics are sent to Matrix.org.

If you would like to set up your own statistics collection server and send metrics there, you may consider using one of the following known implementations: