# Monitor Lightsail resources with health metrics
You can view the following Amazon Lightsail resource metrics over different time periods. For more information about resource metrics in Lightsail, see [Resource metrics](amazon-lightsail-resource-health-metrics.md).
## Instance metrics
The following instance metrics are available. For more information, see [Viewing instance metrics in Amazon Lightsail](amazon-lightsail-viewing-instance-health-metrics.md).
+ **CPU utilization (`CPUUtilization`)** — The percentage of allocated compute units that are currently in use on the instance. This metric identifies the processing power to run the applications on the instance. Tools in your operating system can show a lower percentage than Lightsail when the instance is not allocated a full processor core.
When viewing the CPU utilization metric graphs for your instances in the Lightsail console, you will see sustainable, and burstable zones. For more information about what these zones mean, see [CPU utilization sustainable and burstable zones](https://lightsail.aws.amazon.com/ls/docs/en_us/articles/amazon-lightsail-viewing-instance-health-metrics#cpu-utilization-zones).
+ **Burst capacity minutes (`BurstCapacityTime`) and percentage (`BurstCapacityPercentage`)** — Burst capacity minutes represent the amount of time available for your instance to burst at 100% CPU utilization. Burst capacity percentage is the percentage of CPU performance available to your instance. Your instance continuously consumes and accrues burst capacity. Burst capacity minutes are consumed at the full rate only when your instance operates at 100% CPU utilization. For more information about instance burst capacity, see [View instance burst capacity](amazon-lightsail-viewing-instance-burst-capacity.md).
+ **Incoming network traffic (`NetworkIn`)** — The number of bytes received on all network interfaces by the instance. This metric identifies the volume of incoming network traffic to the instance. The number reported is the number of bytes received during the period. Because this metric is reported in 5-minute intervals, divide the reported number by 300 to find Bytes/second.
+ **Outgoing network traffic (`NetworkOut`)** — The number of bytes sent out on all network interfaces by the instance. This metric identifies the volume of outgoing network traffic from the instance. The number reported is the number of bytes sent during the period. Because this metric is reported in 5-minute intervals, divide the reported number by 300 to find Bytes/second.
+ **Status check failures (`StatusCheckFailed`)** — Reports whether the instance passed or failed both the instance status check and the system status check. This metric can be either 0 (passed) or 1 (failed). This metric is available at a 1-minute frequency.
+ **Instance status check failures (`StatusCheckFailed_Instance`)** — Reports whether the instance passed or failed the instance status check. This metric can be either 0 (passed) or 1 (failed). This metric is available at a 1-minute frequency.
+ **System status check failures (`StatusCheckFailed_System`)** — Reports whether the instance passed or failed the system status check. This metric can be either 0 (passed) or 1 (failed). This metric is available at a 1-minute frequency.
+ **System status check failures (`StatusCheckFailed_System`)** — Reports whether the instance passed or failed the system status check. This metric can be either 0 (passed) or 1 (failed). This metric is available at a 1-minute frequency.
+ **No token metadata requests (`MetadataNoToken`)** — The number of times that the instance metadata service was successfully accessed without a token. This metric determines if there are any processes accessing instance metadata by using Instance Metadata Service Version 1, which doesn't use a token. If all requests use token-backed sessions, such as Instance Metadata Service Version 2, the value is 0. For more information, see [Instance metadata and user data](amazon-lightsail-instance-metadata.md).
## Database metrics
The following database metrics are available. For more information, see [View database metrics](amazon-lightsail-viewing-database-health-metrics.md).
+ **CPU utilization (`CPUUtilization`)** — The percentage of CPU utilization currently in use on the database.
+ **Database connections (`DatabaseConnections`)** — The number of database connections in use.
+ **Disk queue depth (`DiskQueueDepth`)** — The number of outstanding IOs (read/write requests) that are waiting to access the disk.
+ **Free storage space (`FreeStorageSpace`)** — The amount of available storage space.
+ **Network receive throughput (`NetworkReceiveThroughput`)** — The incoming (Receive) network traffic on the database, including both customer database traffic and AWS traffic used for monitoring and replication.
+ **Network transmit throughput (`NetworkTransmitThroughput`)** — The outgoing (Transmit) network traffic on the database, including both customer database traffic and AWS traffic used for monitoring and replication.
## Distribution metrics
The following distribution metrics are available. For more information, see [Viewing distribution metrics in Amazon Lightsail](amazon-lightsail-viewing-distribution-health-metrics.md).
+ **Requests** — The total number of viewer requests received by your distribution, for all HTTP methods, and for both HTTP and HTTPS requests.
+ **Bytes uploaded** — The number of bytes uploaded to your origin by your distribution, using POST and PUT requests.
+ **Bytes downloaded** — The number of bytes downloaded by viewers for GET, HEAD, and OPTIONS requests.
+ **Total error rate** — The percentage of all viewer requests for which the response’s HTTP status code was 4xx or 5xx.
+ **HTTP 4xx error rate** — The percentage of all viewer requests for which the response’s HTTP status code was 4xx. In these cases, the client or client viewer may have made an error. For example, a status code of 404 (Not Found) means that the client requested an object that could not be found.
+ **HTTP 5xx error rate** — The percentage of all viewer requests for which the response’s HTTP status code was 5xx. In these cases, the origin server did not satisfy the request. For example, a status code of 503 (Service Unavailable) means that the origin server is currently unavailable.
## Load balancer metrics
The following load balancer metrics are available. For more information, see [View load balancer metrics](amazon-lightsail-viewing-load-balancer-health-metrics.md).
+ **Healthy host count (`HealthyHostCount`)** — The number of target instances that are considered healthy.
+ **Unhealthy host count (`UnhealthyHostCount`)** — The number of target instances that are considered unhealthy.
+ **Load balancer HTTP 4XX (`HTTPCode_LB_4XX_Count`)** — The number of HTTP 4XX client error codes that originated from the load balancer. Client errors are generated when requests are malformed or incomplete. These requests were not received by the target instance. This count does not include response codes generated by the target instances.
+ **Load balancer HTTP 5XX (`HTTPCode_LB_5XX_Count`)** — The number of HTTP 5XX server error codes that originated from the load balancer. This does not include any response codes generated by the target instance. This metric is reported if there are no healthy instances attached to the load balancer, or if the request rate exceeds the capacity of the instances (spillover) or the load balancer.
+ **Instance HTTP 2XX (`HTTPCode_Instance_2XX_Count`)** — The number of HTTP 2XX response codes generated by the target instances. This does not include any response codes generated by the load balancer.
+ **Instance HTTP 3XX (`HTTPCode_Instance_3XX_Count`)** — The number of HTTP 3XX response codes generated by the target instances. This does not include any response codes generated by the load balancer.
+ **Instance HTTP 4XX (`HTTPCode_Instance_4XX_Count`)** — The number of HTTP 4XX response codes generated by the target instances. This does not include any response codes generated by the load balancer.
+ **Instance HTTP 5XX (`HTTPCode_Instance_5XX_Count`)** — The number of HTTP 5XX response codes generated by the target instances. This does not include any response codes generated by the load balancer.
+ **Instance response time (`InstanceResponseTime`)** — The time elapsed, in seconds, after the request leaves the load balancer until a response from the target instance is received.
+ **Request count (`RequestCount`)** — The number of requests processed over IPv4. This count includes only the requests with a response generated by a target instance of the load balancer.
+ **Client TLS negotiation error count (`ClientTLSNegotiationErrorCount`)** — The number of TLS connections initiated by the client that did not establish a session with the load balancer due to a TLS error generated by the load balancer. Possible causes include a mismatch of ciphers or protocols.
+ **Rejected connection count (`RejectedConnectionCount`)** — The number of connections that were rejected because the load balancer had reached its maximum number of connections.
## Container service metrics
The following container service metrics are available. For more information, see [View container service metrics](amazon-lightsail-viewing-container-services-metrics.md).
+ **CPU utilization** — The average percentage of compute units that are currently in use across all nodes of your container service. This metric identifies the processing power required to run containers on your container service.
+ **Memory utilization** — The average percentage of memory that is currently in use across all nodes of your container service. This metric identifies the memory required to run containers on your container service.
## Bucket metrics
The following bucket metrics are available. For more information, see [View bucket metrics](amazon-lightsail-viewing-bucket-metrics.md).
+ **Bucket size** — The amount of data stored in a bucket. This value is calculated by summing the size of all objects in the bucket (both current and non-current objects), including the size of all parts for all incomplete multipart uploads to the bucket.
+ **Number of objects** — The total number of objects stored in a bucket. This value is calculated by counting all objects in the bucket (both current and non-current objects) and the total number of parts for all incomplete multipart uploads to the bucket.
**Note**
Bucket metric data is not reported when your bucket is empty.
**Topics**
+ [Instance metrics](#understanding-instance-metrics)
+ [Database metrics](#understanding-database-metrics)
+ [Distribution metrics](#understanding-distribution-metrics)
+ [Load balancer metrics](#understanding-load-balancer-metrics)
+ [Container service metrics](#understanding-container-service-metrics)
+ [Bucket metrics](#understanding-bucket-metrics-available)
+ [Metric notifications](amazon-lightsail-notifications.md)
+ [View instance metrics](amazon-lightsail-viewing-instance-health-metrics.md)
+ [Metric alarms](amazon-lightsail-alarms.md)
+ [Create instance alarms](amazon-lightsail-adding-instance-health-metric-alarms.md)
+ [Delete or disable alarms](amazon-lightsail-deleting-health-metric-alarms.md)
# Configure metric notifications for Lightsail resources
You can configure Lightsail to notify you when a metric for one of your instances, databases, load balancers, or content delivery network (CDN) distributions crosses a specified threshold. Notifications can be in the form of a banner displayed in the Lightsail console, an email sent to an address you specify, or an SMS text message sent to a mobile phone number you specify. For more information on how to review your contacts pending verification for notifications, see [Review email contacts pending verification](amazon-lightsail-alarm-notifications.md#amazon-lightsail-alarm-notifications-review-contacts).
To get notifications, you must configure an alarm that monitors a metric for one of your resources. For example, you can configure an alarm that notifies you when your instance's outgoing network traffic is greater than 500 kilobytes during a specified length of time. For more information, see [Metric alarms](amazon-lightsail-alarms.md).
When an alarm is triggered, a notification banner is displayed in the Lightsail console. To be notified by email and SMS text message, you must add your email address and mobile phone number as notification contacts in each AWS Region where you want to monitor your resources. For more information, see [Add notification contacts](amazon-lightsail-adding-editing-notification-contacts.md).
**Note**
SMS text messaging is not supported in all AWS Regions in which you can create Lightsail resources, and text messages cannot be sent to some countries and regions of the world. For more information, see [Add notification contacts](amazon-lightsail-adding-editing-notification-contacts.md).
If don't receive notifications when you expect to be notified, then there are a few things you should check to confirm that your notification contacts are configured correctly. To learn more, see [Troubleshoot notifications](amazon-lightsail-troubleshooting-notifications.md).
To stop receiving notifications, you can remove your email and mobile phone from Lightsail. For more information, see [Delete or disable metric alarms](amazon-lightsail-deleting-notification-contacts.md). You can also disable or delete an alarm to stop receiving notifications for a specific alarm. For more information, see [Delete or disable metric alarms](amazon-lightsail-deleting-health-metric-alarms.md).
# Monitor Lightsail instance performance with metrics
After you launch an instance in Amazon Lightsail, you can view its metric graphs on the **Metrics** tab of the instance’s management page. Monitoring metrics is an important part of maintaining the reliability, availability, and performance of your resources. Monitor and collect metric data from your resources regularly so that you can more readily debug a multi-point failure, if one occurs. For more information about metrics, see [Metrics in Amazon Lightsail](amazon-lightsail-resource-health-metrics.md).
When monitoring your resources, you should establish a baseline for normal resource performance in your environment. Then you can configure alarms in the Lightsail console to notify you when your resources are performing outside of specified thresholds. For more information, see [Notifications](amazon-lightsail-notifications.md) and [Alarms](amazon-lightsail-alarms.md).
**Contents**
+ [Instance metrics available in Lightsail](#instance-metrics)
+ [CPU utilization sustainable and burstable zones](#cpu-utilization-zones)
+ [View instance metrics in the Lightsail console](#viewing-instance-metrics-console)
+ [Next steps after viewing instance metrics](#next-steps-viewing-instance-metrics)
## Available instance metrics
The following instance metrics are available:
+ **CPU utilization (`CPUUtilization`)** — The percentage of allocated compute units that are currently in use on the instance. This metric identifies the processing power to run the applications on the instance. Tools in your operating system can show a lower percentage than Lightsail when the instance is not allocated a full processor core.
When viewing the CPU utilization metric graphs for your instances in the Lightsail console, you will see sustainable, and burstable zones. For more information about what these zones mean, see [CPU utilization sustainable and burstable zones](#cpu-utilization-zones).
+ **Burst capacity minutes (`BurstCapacityTime`) and percentage (`BurstCapacityPercentage`)** — Burst capacity minutes represent the amount of time available for your instance to burst at 100% CPU utilization. Burst capacity percentage is the percentage of CPU performance available to your instance. Your instance continuously consumes and accrues burst capacity. Burst capacity minutes are consumed at the full rate only when your instance operates at 100% CPU utilization. For more information about instance burst capacity, see [View instance burst capacity](amazon-lightsail-viewing-instance-burst-capacity.md).
+ **Incoming network traffic (`NetworkIn`)** — The number of bytes received on all network interfaces by the instance. This metric identifies the volume of incoming network traffic to the instance. The number reported is the number of bytes received during the period. Because this metric is reported in 5-minute intervals, divide the reported number by 300 to find Bytes/second.
+ **Outgoing network traffic (`NetworkOut`)** — The number of bytes sent out on all network interfaces by the instance. This metric identifies the volume of outgoing network traffic from the instance. The number reported is the number of bytes sent during the period. Because this metric is reported in 5-minute intervals, divide the reported number by 300 to find Bytes/second.
+ **Status check failures (`StatusCheckFailed`)** — Reports whether the instance passed or failed both the instance status check and the system status check. This metric can be either 0 (passed) or 1 (failed). This metric is available at a 1-minute frequency.
+ **Instance status check failures (`StatusCheckFailed_Instance`)** — Reports whether the instance passed or failed the instance status check. This metric can be either 0 (passed) or 1 (failed). This metric is available at a 1-minute frequency.
+ **System status check failures (`StatusCheckFailed_System`)** — Reports whether the instance passed or failed the system status check. This metric can be either 0 (passed) or 1 (failed). This metric is available at a 1-minute frequency.
+ **No token metadata requests (`MetadataNoToken`)** — The number of times that the instance metadata service was successfully accessed without a token. This metric determines if there are any processes accessing instance metadata by using Instance Metadata Service Version 1, which doesn't use a token. If all requests use token-backed sessions, such as Instance Metadata Service Version 2, then the value is 0. For more information, see [Instance metadata and user data](amazon-lightsail-instance-metadata.md).
## CPU utilization sustainable and burstable zones
Lightsail uses burstable instances which provide a baseline amount of CPU performance, but also have the ability to temporarily provide additional CPU performance above the baseline as needed. This is referred to as bursting. With burstable instances, you don’t have to over-provision your instance to handle occasional performance spikes—you don’t have to pay for capacity you never use.
On the CPU utilization metric graph for your instances, you will see a sustainable zone, and a burstable zone. Your Lightsail instance can operate in the sustainable zone indefinitely with no impact to the operation of your system.
![\[Sustainable and burstable zones on the CPU utilization graph.\]](http://docs.aws.amazon.com/lightsail/latest/userguide/images/cpu-utilization-burstable-zone.png)
Your instance may begin operating in the burstable zone when under heavy load, such as when compiling code, installing new software, running a batch job, or serving peak load requests. While operating in the burstable zone, your instance is consuming a higher amount of CPU cycles. Therefore, it can only operate in this zone for a limited period of time.
The period of time your instance can operate in the burstable zone is dependent on how far into the burstable zone it is. An instance operating in the lower end of the burstable zone can burst for a longer period of time than an instance operating in the higher end of the burstable zone. However, an instance that is anywhere in the burstable zone for a sustained period of time will eventually use up all the CPU capacity until it operates in the sustainable zone again.
Monitor your instance’s CPU utilization metric to see how its performance is distributed between the sustainable and burstable zones. If your system only occasionally moves into the burstable zone, you should be fine continuing to use the instance that you’re running. However, if you see your instance spending a considerable amount of time in the burstable zone, you might want to switch to a larger plan for your instance (use the \$112 USD/month plan instead of the \$15 USD/month plan). You can switch to a larger plan by creating a new snapshot of your instance, and then creating a new instance from the snapshot.
## View instance metrics in the Lightsail console
Complete the following steps to view instance metrics in the Lightsail console.
1. Sign in to the [Lightsail console](https://lightsail.aws.amazon.com/).
1. In the left navigation pane, choose **Instances**.
1. Choose the name of the instance for which you want to view metrics.
1. Choose the **Metrics** tab on the instance management page.
1. Choose the metric that you want to view in the drop-down menu under the **Metrics graphs** heading.
The graph displays a visual representation of the data points for the chosen metric.
**Note**
When viewing the CPU utilization metric graphs for your instances in the Lightsail console, you will see sustainable, and burstable zones. For more information about these zones, see [CPU utilization sustainable and burstable zones](#cpu-utilization-zones).
1. You can perform the following actions on the metrics graph:
+ Change the view of the graph to show data for 1 hour, 6 hours, 1 day, 1 week, and 2 weeks.
+ Pause your cursor on a data point to view detailed information about that data point.
+ Add an alarm for the chosen metric to be notified when the metric crosses a threshold you specify. For more information, see [Alarms](amazon-lightsail-alarms.md) and [Create instance metric alarms](amazon-lightsail-adding-instance-health-metric-alarms.md).
## Next steps
There are a few additional tasks that you can perform for your instance metrics:
+ Add an alarm for the chosen metric to be notified when the metric crosses a threshold you specify. For more information, see [Metric alarms](amazon-lightsail-alarms.md) and [Create instance metric alarms](amazon-lightsail-adding-instance-health-metric-alarms.md).
+ When an alarm is triggered, a notification banner is displayed in the Lightsail console. To be notified by email and SMS text message, you must add your email address and mobile phone number as notification contacts in each AWS Region where you want to monitor your resources. For more information, see [Add notification contacts](amazon-lightsail-adding-editing-notification-contacts.md).
+ To stop receiving notifications, you can remove your email and mobile phone from Lightsail. For more information, see [Delete or disable metric alarms](amazon-lightsail-deleting-notification-contacts.md). You can also disable or delete an alarm to stop receiving notifications for a specific alarm. For more information, see [Delete or disable metric alarms](amazon-lightsail-deleting-health-metric-alarms.md).
# Metric alarms in Lightsail
You can create an alarm in Amazon Lightsail that watches a single metric for your instances, databases, load balancers, and content delivery network (CDN) distributions. The alarm can be configured to notify you based on the value of the metric relative to a threshold that you specify. Notifications can be a banner displayed in the Lightsail console, an email sent to your email address, and an SMS text message sent to your mobile phone number. In this guide, we describe the alarm conditions and settings that you can configure. For more information on how to review your active alarms across all Lightsail resources, see [Review alarm notifications for active alarms](amazon-lightsail-alarm-notifications.md#amazon-lightsail-alarm-notifications-review-alarms).
**Contents**
+ [Configure an alarm](#configuring-alarm)
+ [Alarms states](#alarm-states)
+ [Alarm example](#alarm-example)
+ [Configure how alarms treat missing data](#missing-data)
+ [How alarm state is evaluated when data is missing](#alarm-evaluation)
+ [Missing data in graphed examples](#missing-data-examples)
+ [More information about alarms](#more-information-alarms)
## Configuring an alarm
To add an alarm in the Lightsail console, browse to the **Metrics** tab of your instance, database, load balancer, or CDN distribution. You then choose the metric you want to monitor, and choose **Add alarm**. You can add two alarms per metric. For more information about metrics, see [Resource metrics](amazon-lightsail-resource-health-metrics.md).
To configure the alarm, you first identify a threshold value, which is the metric value at which point the alarm will change states (e.g., change from an `OK` state to an `ALARM` state, or vice versa). For more information, see [Alarms states](#alarm-states). You then select a comparison operator that will be used to compare the metric to the threshold. The available operators are **greater than or equal to**, **greater than**, **less than**, and **less than or equal to**.
You then specify the number of times the threshold must be crossed, and the period of time the metric will be evaluated, for the alarm to change states. Lightsail evaluates data points for alarms every 5 minutes, and each data point represents a 5 minute period of aggregated data. For example, if you specify the alarm to trigger when the threshold is crossed 2 times, then the evaluation period must be *in the last 10 minutes* or greater (up to 24 hours). If you specify the alarm to trigger when the threshold is crossed 10 times, then the evaluation period must be *in the last 50 minutes* or greater (up to 24 hours).
After you configure the conditions for the alarm, you can configure how you would like to be notified. Notification banners always display in the Lightsail console when the alarm changes from an `OK` state to an `ALARM` state. You can also choose to be notified by email and SMS text message, but you must configure notification contacts for those. For more information, see [Metric notifications](amazon-lightsail-notifications.md). If you choose to be notified by email and/or SMS text message, you can also choose to be notified when the alarm state changes from an `ALARM` state to an `OK` state, which is considered as an *all clear* notification.
Within the **Advanced settings** for the alarm, you can choose how Lightsail treats missing metric data. For more information, see [Configure how alarms treat missing data](#missing-data).
## Alarms states
An alarm is always in one of the following states:
+ **ALARM** — The metric is outside of the defined threshold.
For example, if you choose a **greater than** comparison operator, the alarm will be in an `ALARM` state when the metric is greater than the specified threshold. If you choose a **less than** comparison operator, the alarm will be in an `ALARM` state when the metric is less than the specified threshold.
+ **OK** — The metric is within the defined threshold.
For example, if you choose a **greater than** comparison operator, the alarm will be in an `OK` state when the metric is less than the specified threshold. If you choose a **less than** comparison operator, the alarm will be in an `OK` state when the metric is greater than the specified threshold.
+ **INSUFFICIENT\$1DATA** — The alarm has just started, the metric is not available, or there is not enough metric data available for the alarm to determine the alarm state.
Alarms are triggered for state changes only. Alarms are not triggered simply because they are in a particulate state—the state must have changed. When an alarm is triggered, a banner is displayed in the Lightsail console. You can also configure alarms to notify you by email, and SMS text message.
## Alarm example
With the previously described alarm conditions in mind, you can configure an alarm that goes into an `ALARM` state when an instance’s CPU utilization is greater than or equal to 5 percent one time in a single 5-minute period. The following example shows the settings for this alarm in the Lightsail console.
![\[Example of a CPU utilization alarm.\]](http://docs.aws.amazon.com/lightsail/latest/userguide/images/amazon-lightsail-cpu-utilization-alarm-example.png)
In this example, if the instance’s CPU utilization metric reports a 5 percent or above utilization in just one data point, the alarm changes from an `OK` state to an `ALARM` state. Each subsequent data point reported that is 5 percent or above utilization maintains the alarm at an `ALARM` state. When the instance’s CPU utilization metric reports a 4.9 percent or below utilization in just one data point, the alarm changes from an `ALARM` state to an `OK` state.
The following graph further illustrates this alarm. The dotted red line represents the 5% CPU utilization threshold, and the blue dots represent metric data points. The alarm is in an `OK` state for the first data point. The second data point changes the alarm to an `ALARM` state because the data point is greater than the threshold. The third and fourth data points maintain the `ALARM` state, because the data points continue to be greater than the threshold. The fifth data point changes the alarm to an `OK` state because the data point is less than the threshold.
![\[Example of an alarming metric.\]](http://docs.aws.amazon.com/lightsail/latest/userguide/images/amazon-lightsail-graphed-metric-example.png)
## Configure how alarms treat missing data
In some cases, some data points for a metric with an alarm are not reported. For example, this can happen when a connection is lost, or a server goes down.
Lightsail lets you specify how to treat missing data points when configuring an alarm. This helps you configure your alarm to go to the ALARM state when appropriate for the type of data being monitored. You can avoid false positives when missing data doesn't indicate a problem.
Similar to how each alarm is always in one of three states, each specific data point reported falls under one of three categories:
+ **Breaching** — The data point is outside of the threshold.
For example, if you choose a **greater than** comparison operator, the data point will be `Breaching` when it is greater than the specified threshold. If you choose a **less than** comparison operator, the data point will be `Breaching` when it is less than the specified threshold.
+ **Not breaching** — The data point is within the threshold.
For example, if you choose a **greater than** comparison operator, the data point will be `Not breaching` when it is less than the specified threshold. If you choose a **less than** comparison operator, the data point will be `Not breaching` when it is greater than the specified threshold.
+ **Missing** — The behavior for missing data points is specified by the `treat missing data` parameter.
For each alarm, you can specify Lightsail to treat missing data points as any of the following:
+ **Breaching** — Missing data points are treated as "bad" and breaching the threshold.
+ **Not breaching** — Missing data points are treated as "good" and within the threshold.
+ **Ignore** — The current alarm state is maintained.
+ **Missing** — The alarm doesn't consider missing data points when evaluating whether to change state. This is the default behavior for alarms.
The best choice depends on the type of metric. For a metric such as an instance’s CPU utilization, you might want to treat missing data points as breaching. This is because the missing data points might indicate that something is wrong. But for a metric that generates data points only when an error occurs, such as a load balancer’s HTTP 500 server error count, you might want to treat missing data as not breaching.
Choosing the best option for your alarm prevents unnecessary and misleading alarm condition changes. It also more accurately indicates the health of your system.
**Note**
On the Lightsail console, you can configure how alarms treat missing data under **Advanced settings** when adding or editing an alarm on the **Metrics** tab of your resource. The missing data options are labelled differently on the console as:
**Breaching** corresponds to **Assume the missing data is not within the threshold**.
**Not breaching** corresponds to **Assume the missing data is within the threshold**.
**Ignore** corresponds to **Ignore the missing data**.
**Missing** corresponds to **Do not evaluate the missing data**.
![\[Missing data options on the Lightsail console.\]](http://docs.aws.amazon.com/lightsail/latest/userguide/images/amazon-lightsail-alarms-missing-data.png)
## How alarm state is evaluated when data is missing
No matter what value you set for how to treat missing data, when an alarm evaluates whether to change state, Lightsail attempts to retrieve a greater number of data points than specified by **Evaluation Periods**. The exact number of data points it attempts to retrieve depends on the length of the alarm period. The time frame of the data points that it attempts to retrieve is the evaluation range.
After Lightsail retrieves these data points, the following happens:
+ If no data points in the evaluation range are missing, Lightsail evaluates the alarm based on the most recent data points collected.
+ If some data points in the evaluation range are missing, but the number of existing data points collected is equal to or more than the alarm's **Evaluation periods**, Lightsail evaluates the alarm state based on the most recent existing data points that were successfully collected. In this case, the value you set for how to treat missing data is not needed, and is then ignored.
+ If some data points in the evaluation range are missing, and the number of existing data points that were collected is less than the alarm's number of **Evaluation periods**, Lightsail fills in the missing data points with the result you specified for how to treat missing data, and then evaluates the alarm. However, any real data points in the evaluation range, no matter when they were reported, are included in the evaluation. Lightsail uses missing data points only as few times as possible.
In all of these situations, the number of data points evaluated is equal to the value of **Evaluation periods**. If fewer than the value of **Data points to alarm** are breaching, the alarm state is set to OK. Otherwise, the state is set to ALARM.
**Note**
A particular case of this behavior is that Lightsail alarms might repeatedly re-evaluate the last set of data points for a period of time after the metric has stopped flowing. This re-evaluation might cause the alarm to change state and re-execute actions, if it had changed state immediately before the metric stream stopping. To mitigate this behavior, use shorter periods.
## Missing data in graphed examples
The following graphs in this section help illustrate examples of the alarm evaluation behavior. In graphs A, B, C, D, and E, the number data points that must be breaching to alarm, and the evaluation periods, are both 3. The dotted red line represents the threshold, the blue dots represent valid data points, and the dashes represent missing data. Data points above the threshold line are breaching, and data points below the threshold are not breaching. In case some of the most recent three data points are missing, Lightsail will attempt to retrieve additional valid data points.
**Note**
If data points are missing soon after you create an alarm, and the metric was being reported to Lightsail before you created the alarm, Lightsail retrieves the most recent data points from before the alarm was created when evaluating the alarm.
### Graph A
![\[Missing data graph A.\]](http://docs.aws.amazon.com/lightsail/latest/userguide/images/amazon-lightsail-alarm-graph-a.png)
In the preceding graphed metric, data point 1 is within threshold, data point 2 is missing, data point 3 is breaching, data point 4 is missing, and data point 5 is breaching. Given that there are three valid data points in the evaluation range, this metric has zero missing data points. If you configured an alarm to treat missing data points as:
+ **Not breaching** — The alarm would be in an OK state.
+ **Breaching** — The alarm would be in an OK state.
+ **Ignore** — The alarm would be in an OK state.
+ **Missing** — The alarm would be in an OK state.
### Graph B
![\[Missing data graph B.\]](http://docs.aws.amazon.com/lightsail/latest/userguide/images/amazon-lightsail-alarm-graph-b.png)
In the preceding graphed metric, data point 1 is within threshold, and data points 2 through 5 are missing. Given that there is only one data point in the evaluation range, this metric has two missing data points. If you configured an alarm to treat missing data points as:
+ **Not breaching** — The alarm would be in an OK state.
+ **Breaching** — The alarm would be in an OK state.
+ **Ignore** — The alarm would be in an OK state.
+ **Missing** — The alarm would be in an OK state.
In this scenario, the alarm would stay in an OK state, even if missing data is treated as breaching. This is because the one existing data point is not breaching, and this is evaluated along with two missing data points that are treated as breaching. The next time this alarm is evaluated, if the data is still missing it goes to ALARM. This is because that non-breaching data point is no longer be among the five most recent data points retrieved.
### Graph C
![\[Missing data graph C.\]](http://docs.aws.amazon.com/lightsail/latest/userguide/images/amazon-lightsail-alarm-graph-c.png)
All data points are missing in the preceding graphed metric. Given that all data points are missing in the evaluation range, this metric has three missing data points. If you configured an alarm to treat missing data points as:
+ **Not breaching** — The alarm would be in an OK state.
+ **Breaching** — The alarm would be in an ALARM state.
+ **Ignore** — The alarm would maintain the current state.
+ **Missing** — The alarm would be in an INSUFFICIENT\$1DATA state.
### Graph D
![\[Missing data graph D.\]](http://docs.aws.amazon.com/lightsail/latest/userguide/images/amazon-lightsail-alarm-graph-d.png)
In the preceding graphed metric, data point 1 is within threshold, data point 2 is breaching, data point 3 is breaching, data point 4 is missing, and data point 5 is breaching. Given that there are four valid data points in the evaluation range, this metric has zero missing data points. If you configured an alarm to treat missing data points as:
+ **Not breaching** — The alarm would be in an ALARM state.
+ **Breaching** — The alarm would be in an ALARM state.
+ **Ignore** — The alarm would be in an ALARM state.
+ **Missing** — The alarm would be in an ALARM state.
In this scenario, the alarm goes to ALARM state in all cases. This is because there are enough real data points that the setting for how to treat missing data is not needed, and is then ignored.
### Graph E
![\[Missing data graph E.\]](http://docs.aws.amazon.com/lightsail/latest/userguide/images/amazon-lightsail-alarm-graph-e.png)
In the preceding graphed metric, data points 1 and 2 are missing, data point 3 is breaching, and data point 4 and 5 are missing. Given that there is only one data point in the evaluation range, this metric has two missing data points. If you configured an alarm to treat missing data points as:
+ **Not breaching** — The alarm would be in an OK state.
+ **Breaching** — The alarm would be in an ALARM state.
+ **Ignore** — The alarm would maintain the current state.
+ **Missing** — The alarm would be in an ALARM state.
In graphs F, G, H, I, and J, the **Datapoints to alarm** is 2 while **Evaluation periods** is 3. This is a 2 out of 3, M out of N alarm. 5 is the evaluation range for the alarm.
### Graph F
![\[Missing data graph F.\]](http://docs.aws.amazon.com/lightsail/latest/userguide/images/amazon-lightsail-alarm-graph-f.png)
In the preceding graphed metric, data point 1 within threshold, data point 2 is missing, data point 3 is breaching, data point 4 is missing, and data point 5 is breaching. Given that there are three data points in the evaluation range, this metric has zero missing data points. If you configured an alarm to treat missing data points as:
+ **Not breaching** — The alarm would be in an ALARM state.
+ **Breaching** — The alarm would be in an ALARM state.
+ **Ignore** — The alarm would be in an ALARM state.
+ **Missing** — The alarm would be in an ALARM state.
### Graph G
![\[Missing data graph G.\]](http://docs.aws.amazon.com/lightsail/latest/userguide/images/amazon-lightsail-alarm-graph-g.png)
In the preceding graphed metric, data points 1 and 2 are within threshold, data point 3 is breaching, data point 4 is within threshold, data point 5 is breaching. Given that there are five data points in the evaluation range, this metric has zero missing data points. If you configured an alarm to treat missing data points as:
+ **Not breaching** — The alarm would be in an ALARM state.
+ **Breaching** — The alarm would be in an ALARM state.
+ **Ignore** — The alarm would be in an ALARM state.
+ **Missing** — The alarm would be in an ALARM state.
### Graph H
![\[Missing data graph H.\]](http://docs.aws.amazon.com/lightsail/latest/userguide/images/amazon-lightsail-alarm-graph-h.png)
In the preceding graphed metric, data point 1 is within threshold, data point 2 is missing, data point 3 is breaching, and data points 4 and 5 are missing. Given that there are two data points in the evaluation range, this metric has one missing data point. If you configured an alarm to treat missing data points as:
+ **Not breaching** — The alarm would be in an OK state.
+ **Breaching** — The alarm would be in an ALARM state.
+ **Ignore** — The alarm would be in an OK state.
+ **Missing** — The alarm would be in an OK state.
### Graph I
![\[Missing data graph I.\]](http://docs.aws.amazon.com/lightsail/latest/userguide/images/amazon-lightsail-alarm-graph-i.png)
In the preceding graphed metric, data points 1 through 4 are missing, and data point 5 is within threshold. Given that there is one data point in the evaluation range, this metric has two missing data points. If you configured an alarm to treat missing data points as:
+ **Not breaching** — The alarm would be in an OK state.
+ **Breaching** — The alarm would be in an ALARM state.
+ **Ignore** — The alarm would be in an OK state.
+ **Missing** — The alarm would be in an OK state.
### Graph J
![\[Missing data graph J.\]](http://docs.aws.amazon.com/lightsail/latest/userguide/images/amazon-lightsail-alarm-graph-j.png)
In the preceding graphed metric, data points 1 and 2 are missing, data point 3 is breaching, and data point 4 and 5 are missing. Given that there is one data point in the evaluation range, this metric has two missing data points. If you configured an alarm to treat missing data points as:
+ **Not breaching** — The alarm would be in an OK state.
+ **Breaching** — The alarm would be in an ALARM state.
+ **Ignore** — The alarm would maintain the current state.
+ **Missing** — The alarm would be in an ALARM state.
## More information about alarms
Here are some articles to help you manage alarms in Lightsail:
+ [Create instance metric alarms](amazon-lightsail-adding-instance-health-metric-alarms.md)
+ [Create database metric alarms](amazon-lightsail-adding-database-health-metric-alarms.md)
+ [Create load balancer metric alarms](amazon-lightsail-adding-load-balancer-health-metric-alarms.md)
+ [Create distribution metric alarms](amazon-lightsail-adding-distribution-health-metric-alarms.md)
+ [Delete or disable metric alarms](amazon-lightsail-deleting-health-metric-alarms.md)
# Create Lightsail instance metric alarms
You can create an Amazon Lightsail alarm that watches a single instance metric. An alarm can be configured to notify you based on the value of the metric relative to a threshold that you specify. Notifications can be a banner displayed in the Lightsail console, an email sent to your email address, and an SMS text message sent to your mobile phone number. For more information about alarms, see [Alarms](amazon-lightsail-alarms.md).
**Contents**
+ [Instance alarm limits](#instance-alarm-limits)
+ [Best practices for configuring instance alarms](#instance-alarms-best-practices)
+ [Default alarm settings](#default-instance-alarm-settings)
+ [Create instance metric alarms using the Lightsail console](#creating-instance-alarms)
+ [Test instance metric alarms using the Lightsail console](#testing-instance-alarms)
+ [Next steps after creating instance alarms](#next-steps-creating-instance-alarms)
## Instance alarm limits
The following limits apply to alarms:
+ You can configure two alarms per metric.
+ Alarms are evaluated in 5 minute intervals, and each data point for alarms represents a 5 minute period of aggregated metric data.
+ You can only configure an alarm to notify you when the alarm state changes to `OK` if you configure the alarm to notify you by email and/or SMS text message.
+ You can only test the `OK` alarm notification if you configure the alarm to notify you by email and/or SMS text message.
+ You can only configure an alarm to notify you when the alarm state changes to `INSUFFICIENT_DATA` if you configure the alarm to notify you by email and/or SMS text message, and if you choose the **Do not evaluate the missing data** option for missing data points.
+ You can only test notifications if the alarm is in an OK state.
## Best practices for configuring instance alarms
Before you configure a metric alarm for your instance, you should view the historical data of the metric. Identify the metric's low-levels, mid-levels, and high-levels over a period of the last two weeks. In the following outgoing network traffic (`NetworkOut`) metric graph example, the low-levels are 0-10 KB per hour, the mid-levels are between 10-20 KB per hour, and the high-levels are between 20-80 KB per hour.
![\[Instance NetworkOut example.\]](http://docs.aws.amazon.com/lightsail/latest/userguide/images/amazon-lightsail-networkout-graph-example.png)
If you configure the alarm threshold to be **greater than or equal to** somewhere in the low-level range (e.g., 5 KB per hour), then you will get more frequent, and potentially unnecessary alarm notifications. If you configure the alarm threshold to be **greater than or equal to** somewhere in the high-level range (e.g., 20 KB per hour), then you will get less frequent alarm notifications, but that might be more important to investigate. When you configure an alarm, and enable it, an alarm line representing the threshold appears on the graph as shown in the following example. The alarm line labeled as 1 represents the threshold for Alarm 1, and the alarm line labeled as 2 represents the threshold for Alarm 2.
![\[Instance NetworkOut example, with alarm line.\]](http://docs.aws.amazon.com/lightsail/latest/userguide/images/amazon-lightsail-networkout-graph-example-alarmed.png)
## Default alarm settings
Default alarm settings are prepopulated when you add a new alarm in the Lightsail console. That is the recommended alarm configuration for the metric you selected. However, you should confirm that the default alarm configuration is appropriate for your resource. For example, the default alarm threshold for the instance outgoing network traffic (`NetworkOut`) metric is **less than or equal to** 0 Bytes for 2 times within the last 10 minutes. However, if you're interested in being notified of a high traffic event, then you might want to modify the alarm threshold to be **greater than or equal to** 50 KB for 2 times within the last 10 minutes, or add a second alarm with these settings so that you're notified when there is no traffic, and when there is high traffic. The threshold that you specify should be adjusted to match the metric high-levels and low-levels as described in the [Best practices for configuring instance alarms](#instance-alarms-best-practices) section of this guide.
## Create instance metric alarms using the Lightsail console
Complete the following steps to create an instance metric alarm using the Lightsail console.
1. Sign in to the [Lightsail console](https://lightsail.aws.amazon.com/).
1. In the left navigation pane, choose **Instances**.
1. Choose the name of the instance for which you want to create alarms.
1. Choose the **Metrics** tab on the instance management page.
1. Choose the metric for which you want to create an alarm in the drop-down menu under the **Metrics Graphs** heading. For more information, see [Resource metrics](amazon-lightsail-resource-health-metrics.md).
1. Choose **Add alarm** in the **Alarms** section of the page.
1. Choose a comparison operator value in the drop-down menu. Example values are greater than or equal to, greater than, less than, or less than or equal to.
1. Enter a threshold for the alarm.
1. Enter the data points to alarm.
1. Choose the evaluation periods. The period can be specified in 5-minute increments, from 5 minutes up to 24 hours.
1. Choose one of the following notification methods:
+ **Email** — You are notified by email when the alarm state changes to ALARM.
+ **SMS text message** — You are notified by SMS text message when the alarm state changes to ALARM. SMS messaging is not supported in all AWS Regions in which you can create Lightsail resources, and SMS text messages cannot be sent to all countries/regions. For more information, see [SMS text messaging support](https://lightsail.aws.amazon.com/ls/docs/en_us/articles/amazon-lightsail-adding-editing-notification-contacts#sms-support).
**Note**
You are required to add an email address or mobile phone number if you select to be notified by email or SMS but you haven’t yet configured a notification contact in the resource’s AWS Region. For more information, see [Metric notifications](amazon-lightsail-notifications.md).
1. (Optional) Choose **Send me a notification when the alarm state change to OK** to be notified when the alarm state changes to OK. This option is available only if you choose to be notified by Email or SMS text message.
1. (Optional) Choose **Advanced settings**, and then choose one of the following options:
+ Choose how the alarm should treat missing data. The following options are available:
+ **Assume it's not within the threshold (Breaching threshold)** — Missing data points are treated as "bad" and breaching the threshold.
+ **Assume it's within the threshold (Not breaching threshold)** — Missing data points are treated as "good" and within the threshold.
+ **Use the value of the last good data point (Ignore and maintain the current alarm state)** — The current alarm state is maintained.
+ **Do not evaluate it (Treat missing data as missing)** — The alarm doesn't consider missing data points when evaluating whether to change state.
+ Choose **Send a notification if there is insufficient data** to be notified when the alarm state changes to INSUFFICIENT\$1DATA. This option is available only if you choose to be notified by Email or SMS text message.
1. Choose **Create** to add the alarm.
To edit the alarm later, choose the ellipsis icon (⋮) next to the alarm you want to edit, and choose **Edit alarm**.
## Test instance metric alarms using the Lightsail console
Complete the following steps to test an alarm using the Lightsail console. You might want to test an alarm to confirm that the configured notification options are working, such as to ensure that you receive an email or an SMS text message when the alarm is triggered.
1. Sign in to the [Lightsail console](https://lightsail.aws.amazon.com/).
1. In the left navigation pane, choose **Instances**.
1. Choose the name of the instance for which you want to test an alarm.
1. Choose the **Metrics** tab on the instance management page.
1. Choose the metric for which you want to test an alarm in the drop-down menu under the **Metrics Graphs** heading.
1. Scroll down to the **Alarms** section of the page, and choose the ellipsis icon (⋮) next to the alarm you want to test.
1. Choose one of the following options:
+ **Test alarm notification** — Choose this option to test the notifications for when the alarm state changes to `ALARM`.
+ **Test OK notification** — Choose this option to test the notifications for when the alarm state changes to `OK`.
**Note**
If either of these options is unavailable, you might not have configured the notification options for the alarm, or the alarm might currently be in an `ALARM` state. For more information, see [Instance alarm limits](#instance-alarm-limits).
The alarm momentarily changes to an `ALARM` or `OK` state depending on the test option you chose, and an email and/or SMS text message is sent depending on what you configured as the notification method for the alarm. A notification banner displays in the Lightsail console only if you chose to test the `ALARM` notification. A notification banner is not displayed if you chose to test the `OK` notification. The alarm will return to its actual state often after a few seconds.
## Next steps
There are a few additional tasks that you can perform for your instance alarms:
+ To stop receiving notifications, you can remove your email and mobile phone from Lightsail. For more information, see [Delete notification contacts](amazon-lightsail-deleting-notification-contacts.md). You can also disable or delete an alarm to stop receiving notifications for a specific alarm. For more information, see [Delete or disable metric alarms](amazon-lightsail-deleting-health-metric-alarms.md).
# Delete or disable Lightsail metric alarms
You can delete an Amazon Lightsail alarm to stop notifications of when the metric being monitored by the alarm crosses a threshold. You can also disable the alarm to stop receiving notifications. For more information, see [Alarms](amazon-lightsail-alarms.md).
**Contents**
+ [Delete metric alarms using the Lightsail console](#deleting-alarms)
+ [Disable and enable metric alarms using the Lightsail console](#disable-alarms)
## Delete metric alarms using the Lightsail console
Complete the following steps to delete a metric alarm using the Lightsail console.
1. Sign in to the [Lightsail console](https://lightsail.aws.amazon.com/).
1. In the left navigation pane, choose **Instances**, **Databases**, or **Networking**.
1. Choose the name of the resource (instance, database, or load balancer) for which you want to delete an alarm.
1. Choose the **Metrics** tab on the resource’s management page.
1. Choose the metric for which you want to delete an alarm in the drop-down under the **Metrics Graphs** heading.
1. Scroll down to the **Alarms** section of the page, and choose the ellipsis icon (⋮) next to the alarm you want to delete.
1. Choose **Delete**.
1. At the prompt, choose **Delete** to confirm that you want to delete the alarm.
## Disable and enabling metric alarms using the Lightsail console
Complete the following steps to disable a metric alarm using the Lightsail console.
1. Sign in to the [Lightsail console](https://lightsail.aws.amazon.com/).
1. In the left navigation pane, choose **Instances**, **Databases**, or **Networking**.
1. Choose the name of the resource (instance, database, or load balancer) for which you want to disable an alarm.
1. Choose the **Metrics** tab on the resource’s management page.
1. Choose the metric for which you want to disable an alarm in the drop-down under the **Metrics Graphs** heading.
1. Scroll down to the **Alarms** section of the page, locate the alarm you want to disable, and choose the toggle to disable it. Likewise, choose the toggle to enable it if it's disabled.