# Event Types > The predefined event types you can base thresholds and events on, including the AutoSteps types. Source: https://docs.capaone.com/performanceguard/administration/manage-thresholds-and-events/event-types/ Product: PerformanceGuard — a separate CapaSystems product; do not apply this page to any other. Event types are predefined types of events that you can base your [Manage Thresholds and Events](/performanceguard/administration/manage-thresholds-and-events/) on: # **AutoSteps** For **AutoSteps activities** registered in PerformanceGuard, the following event types exist: - **Availability**: An event can occur if a transaction isn't responding. :::note[Important]
When is something considered to be available? To answer this we need to look at response times: If response times are so long that use of a service, website, transaction or similar becomes impossible, PerformanceGuard considers the service, etc. to be *un*available. By default, PerformanceGuard loses its patience with a service, etc. if it hasn't responded within 500,000 milliseconds (that's a little more than eight minutes). Everything that's not *un*available, is considered by PerformanceGuard to be available. So, if you see that a service has been 100% available during the last week, it means that it has not exceeded the acceptable response time limit during the last week.
Do you measure availability of application pings (HTTP requests, ICMP ping and/or traceroutes)? For **[Monitor Availability, Latency and Response Times with Application Ping](..\Manage%20Agent%20Configuration%20Groups\Agent%20Configuration%20Group%20Settings\Monitor%20Availability,%20Latency%20and%20Response%20Times%20with%20Application%20Ping.md)**, PerformanceGuard looks not only at acceptable response times, but also at whether a response is expected or not: If the response is unexpected, for example if the response has a response code of *404 Not Found*, PerformanceGuard considers the service to be *un*available, even if the response was received within acceptable time.
::: - **Response Time**: An event can occur if one transaction response time exceeds a threshold value in milliseconds. # **Citrix** For all monitored [I Want to Know If Citrix Works OK](/performanceguard/i-want-to-know/i-want-to-know-if-citrix-works-ok/) sessions you can set absolute thresholds for : - **Session Latency**: An event can occur if latency exceeds a threshold value in milliseconds. - **Session Startup Time**: An event can occur if startup time exceeds a threshold value in milliseconds. # **Computer** Computer event types relate to computer/desktop activity: - **Any Process CPU Usage**: If any process on a computer exceeds a CPU usage threshold value, an event can occur. This can be useful for detecting runaway processes or harmful software. - **Machine Resource Usage**: If a computer exceeds a total CPU, memory or context switch threshold value, an event can occur. - **Network Offline**: If, in a network group, the number of computers that send data goes below a certain limit, the network group is considered to be offline, and an event can occur. The number of computers in a network group must be more than three to trigger the event. - **Network Retransmissions**: If the total number of TCP retransmissions for a computer exceeds a threshold value in percent, an event can occur. - **Process Resource Usage**: If a named process exceeds a CPU or memory usage threshold value, an event can occur. This can be useful for monitoring important processes on servers and getting an early warning if processes begin to use excessive amounts of resources. - **Server Connections**: If the rate of contacted IP addresses for one computer exceeds a threshold, an event can occur. This can be useful for detecting port scanners and worms. - **Startup Time**: An event can occur if the startup time of a computer exceeds a threshold value in seconds. - **User Login Time**: An event can occur if the login time of a user on a computer exceeds a threshold value in seconds. # **IP Service** All IP services are identified by a server group and port group: - **Availability**: An event can occur if a request didn't receive a response. :::note[Important]
When is something considered to be available? To answer this we need to look at response times: If response times are so long that use of a service, website, transaction or similar becomes impossible, PerformanceGuard considers the service, etc. to be *un*available. By default, PerformanceGuard loses its patience with a service, etc. if it hasn't responded within 500,000 milliseconds (that's a little more than eight minutes). Everything that's not *un*available, is considered by PerformanceGuard to be available. So, if you see that a service has been 100% available during the last week, it means that it has not exceeded the acceptable response time limit during the last week.
Do you measure availability of application pings (HTTP requests, ICMP ping and/or traceroutes)? For **[Agent Configuration Group Settings](/performanceguard/administration/manage-agent-configuration-groups/agent-configuration-group-settings/)**, PerformanceGuard looks not only at acceptable response times, but also at whether a response is expected or not: If the response is unexpected, for example if the response has a response code of *404 Not Found*, PerformanceGuard considers the service to be *un*available, even if the response was received within acceptable time.
::: - **Average RTT**: An event can occur if the average round trip time (RTT) within a report interval for a TCP connection exceeds a threshold value in milliseconds. - **Protocol Response Time**: An event can occur if the average protocol transaction response time within a report interval exceeds a threshold value in milliseconds. - **Response Time**: An event can occur if the average response time within a report interval exceeds a threshold value in milliseconds. - **TCP Retransmissions**: An event can occur if the percentage of TCP retransmissions within a report interval exceeds a threshold value. - **Application Online**: Created automatically when defining applications in PerformanceGuard. An event is triggered when a computer reports communication with the application. # **Ping & Traceroute** You can base events of these types on thresholds for: - **Availability** :::note[Important]
When is something considered to be available? To answer this we need to look at response times: If response times are so long that use of a service, website, transaction or similar becomes impossible, PerformanceGuard considers the service, etc. to be *un*available. By default, PerformanceGuard loses its patience with a service, etc. if it hasn't responded within 500,000 milliseconds (that's a little more than eight minutes). Everything that's not *un*available, is considered by PerformanceGuard to be available. So, if you see that a service has been 100% available during the last week, it means that it has not exceeded the acceptable response time limit during the last week.
Do you measure availability of application pings (HTTP requests, ICMP ping and/or traceroutes)? For **[Agent Configuration Group Settings](/performanceguard/administration/manage-agent-configuration-groups/agent-configuration-group-settings/)**, PerformanceGuard looks not only at acceptable response times, but also at whether a response is expected or not: If the response is unexpected, for example if the response has a response code of *404 Not Found*, PerformanceGuard considers the service to be *un*available, even if the response was received within acceptable time.
::: - **Response Time** For more information about the PerformanceGuard ping and traceroute features, see [Monitor Availability, Latency and Response Times with Application Ping](..\Manage%20Agent%20Configuration%20Groups\Agent%20Configuration%20Group%20Settings\Monitor%20Availability,%20Latency%20and%20Response%20Times%20with%20Application%20Ping.md). # **Transaction** You can base events of this type on thresholds for: - **Availability** :::note[Important]
When is something considered to be available? To answer this we need to look at response times: If response times are so long that use of a service, website, transaction or similar becomes impossible, PerformanceGuard considers the service, etc. to be *un*available. By default, PerformanceGuard loses its patience with a service, etc. if it hasn't responded within 500,000 milliseconds (that's a little more than eight minutes). Everything that's not *un*available, is considered by PerformanceGuard to be available. So, if you see that a service has been 100% available during the last week, it means that it has not exceeded the acceptable response time limit during the last week.
Do you measure availability of application pings (HTTP requests, ICMP ping and/or traceroutes)? For **[Agent Configuration Group Settings](/performanceguard/administration/manage-agent-configuration-groups/agent-configuration-group-settings/)**, PerformanceGuard looks not only at acceptable response times, but also at whether a response is expected or not: If the response is unexpected, for example if the response has a response code of *404 Not Found*, PerformanceGuard considers the service to be *un*available, even if the response was received within acceptable time.
::: - **Response Time** For more information about transaction measurement, see [Monitor Complex Activity with AutoSteps](/performanceguard/administration/more-setup/monitor-complex-activity-with-autosteps/).