Imagine your organization has one team for internal IT services, and another for public services. Each team operates independently and is only responsible for its own services. In this scenario, you might set up separate Heartbeat instances for each team, writing out to index patterns named it-heartbeat-\*, and external-heartbeat-\*. You would create separate roles and users for each in Elasticsearch, each with access to their own spaces, named it and external respectively. Within each space you would navigate to the settings page and set the correct index pattern to match only the indices that space is allowed to access.

Note: The pattern set here only restricts what the Uptime app shows. Users may still be able to manually query Elasticsearch for data outside this pattern.

See the Uptime security and Heartbeat security docs for more information.

You can modify settings in this section to control how Uptime will visualize your TLS values in the Certificates page. These settings also determine which certificates will be selected by any TLS alert you define.

There are two fields, age and expiration. Use the age threshold to specify when Uptime should warn you about certificates that have been valid for too long. Use the expiration threshold to specify when Uptime should warn you about certificates that have approaching expiration dates.

For example, a common security requirement is to make sure that none of your organization’s TLS certificates have been valid for longer than one year. Modifying the Age limit field’s value to 365 days will help you keep track of which certificates you may want to refresh.

Likewise, to see which of your TLS certificates are close to expiring ahead of time, specify an Expiration threshold on this page. When the count of a certificate’s remaining valid days falls below this threshold, Uptime will consider it in a warning state. When you define a TLS alert, you receive a notification from Uptime about the certificate.