Alerts tab
You can enable email alerts to be raised when a significant error occurs on your Couchbase Server cluster. The email alert system works by sending email directly to a configured SMTP server. Each alert email is send to the list of configured email recipients. This is used to highlight specific issues and problems that you should be aware of and may need to check to ensure the health of your Couchbase cluster. Alerts are provided as a popup within the web console.
Select Enable email alerts to configure email alerts including the server settings and recipient information. Email alerts are raised for the errors selected in the Available Alerts section.
![](../images/web-console-server-settings-alerts.png)
Email Server Settings
The available settings are:
Options | Description |
---|---|
Host | The hostname for the SMTP server that will be used to send the email. |
Port | The TCP/IP port to be used to communicate with the SMTP server. The default is the standard SMTP port 25. |
Username | For email servers that require a username and password to send email, the username for authentication. |
Password | For email servers that require a username and password to send email, the password for authentication. |
Require TSL | Enable Transport Layer Security (TLS) when sending the email through the designated server. |
Email Settings
Option | Description |
---|---|
Sender email | The email address from which the email will be identified as being sent from. This email address should be one that is valid as a sender address for the SMTP server that you specify. |
Recipients | A list of the recipients of each alert message. To specify more than one recipien, separate each address by a space, comma, or semicolon. |
Test Mail | Click Test Mail to send a test email to confirm the settings and configuration of the email server and recipients. |
Available Alerts
You can enable individual alert messages that can be sent by using the series of checkboxes. The supported alerts are:
Alert | Description |
---|---|
Node was auto-failovered | The sending node has been auto-failovered. |
Maximum number of auto-failovered nodes was reached | The auto-failover system stops auto-failover when the maximum number of spare nodes available has been reached. |
Node wasn't auto-failovered as other nodes are down at the same time | Auto-failover does not take place if there are no spare nodes within the current cluster. |
Node wasn't auto-failovered as the cluster was too small (less than 3 nodes) | You cannot support auto-failover with less than 3 nodes. |
Node's IP address has changed unexpectedly | The IP address of the node has changed, which may indicate a network interface, operating system, or other network or system failure. |
Disk space used for persistent storage has reach at least 90% of capacity | The disk device configured for storage of persistent data is nearing full capacity. |
Metadata overhead is more than 50% | The amount of data required to store the metadata information for your dataset is now greater than 50% of the available RAM. |
Bucket memory on a node is entirely used for metadata | All the available RAM on a node is being used to store the metadata for the objects stored. This means that there is no memory available for caching values,. With no memory left for storing metadata, further requests to store data will also fail. |
Writing data to disk for a specific bucket has failed | The disk or device used for persisting data has failed to store persistent data for a bucket. |