Issue Classification. When reporting an Issue, the severity of the Issue will be classified based on the impact to Customer's business operations in accordance with the severity classification table below. To the extent that Xxxxx disagrees with any Issue classification provided by Xxxxxxxx, Xxxxx will promptly inform Customer of the revised classification of any Issue and the parties will resolve through good faith negotiations any disagreement regarding classification. Priority Business Impact Issue description 1 Critical Yes Trouble conditions where a Wazuh manager is completely out of service and is causing business impact to the customer. 2 High Yes Trouble conditions where a Wazuh manager or deployed agent is not fully functional and is causing business impact to the customer. 3 Medium No Trouble conditions where a Wazuh manager or deployed agent is not fully functional but is not causing business impact to the customer. 4 Low No Any condition or request for assistance that is not causing business impact to the customer. This priority is also used for information exchange and feature requests.
Issue Classification. Upon receipt of any notification to Provider via the Service Desk that an Incident exists (each an “Incident Notification”), Provider shall promptly notify the applicable Recipient Party of such Incident Notification, and such Recipient Party shall assess and assign the classification of the Incident in accordance with the table below. Provider shall communicate with the applicable Recipient Party regarding the Incident and provide a Resolution to the Incident in accordance with this Section 4 of this Schedule 4.1. Resolution steps may include, without limitation, checking against known errors or problems so that previously identified workarounds, error corrections and other resolutions can be quickly implemented, following documented procedures (including the Disaster Recovery Plan, if applicable) to correct the Incident or dispatching the Incident to an appropriate third Person for resolution. Provider’s responsibility to provide Support to each Recipient Party and End Customers receiving or using Services under this Agreement commences upon the receipt of any Incident Notification. If, during the Term, a Recipient Party’s own Personnel or help desk is contacted by any End Customer with a request for assistance with an Incident regarding the Services or operation of the Platform, the applicable Recipient Party will forward such inquiry to Provider’s Service Desk, which forwarded request shall constitute an Incident Notification for the purposes of this Schedule 4.1. Emergency An Incident affecting the Critical Business Functions with impact to greater than 30% of a Recipient Party’s End Customers Within thirty (30) minutes after receipt of report of Incident or discovery of Incident through Provider’s monitoring system; Provide on-going status reports every two (2) hours thereafter Within six (6) hours after receipt of report of Incident or discovery of Incident through Provider’s monitoring system High An Incident affecting the Critical Business Functions with impact to over 15% but no more than 30% of a Recipient Party’s End Customers Within one (1) hour after receipt of report or discovery of Incident through Provider’s monitoring system; Provide on-going status reports every four (4) hours thereafter Within three (3) Business Days after receipt of report or discovery of Incident through Provider’s monitoring system
Issue Classification. When reporting an Issue, the severity of the Issue will be classified based on the impact to Customer's business operations in accordance with the severity classification table below. To the extent that Xxxxx disagrees with any Issue classification provided by Xxxxxxxx, Xxxxx will promptly inform Customer of the revised classification of any Issue and the parties will resolve through good faith negotiations any disagreement regarding classification.
Issue Classification. In its notice of an Issue, Customer will reasonably classify for Supplier the initial priority of the Issue. Customer will use the nature of the Issue and Customer's business situation to initially classify each Issue. Customer will classify each Issue in accordance with the severity classification table below. To the extent that Supplier disagrees with any Issue classification provided by Customer, Supplier will promptly advise Customer of the revised classification of any Issue.
Issue Classification. Assurance, Maintenance and repair tickets are categorised into severity levels based on the volume of End Users impacted or the severity of the system degradation. See tables 3 – table 5 for more information. Note - If a fault on a service or network is caused by third party damage, this is not counted in any service level calculation until the issue is resolved. Severity 1 0.50% Severity 2 0.05% Severity 3 NA Severity 1 NA Severity 2 0.50% Severity 3 0.05% Severity 1 2.00% Severity 2 0.10% Severity 3 0.05% Severity 1 NA Severity 2 2.00% Severity 3 0.50% Severity 4 0.05% Severity 1 0.35% Severity 2 0.02% Severity 3 NA Severity 1 NA Severity 2 0.35% Severity 3 0.02% Severity 1 0.75% Severity 2 0.07% Severity 3 0.02% Severity 1 NA Severity 2 0.75% Severity 3 0.35% Severity 4 0.02% Severity 1 SCP 0.70% Severity 2 SCP 0.10% Severity 3 SCP NA Severity 1 SCP NA Severity 2 SCP 0.70% Severity 3 SCP 0.10% Severity 1 SCP 1.50% Severity 2 SCP 0.35% Severity 3 SCP 0.10% Severity 1 SCP NA Severity 2 SCP 1.50% Severity 3 SCP 0.70%
Issue Classification. Assurance, Maintenance and repair tickets are categorised into severity levels based on the volume of End Users impacted. Table 3: Residential and Business Issue Classification Severity 1 Residential >1000 Severity 1 Business >500 Severity 2 Residential 000 -000 Xxxxxxxx 2 Business 250 - 499 Severity 3 Residential 000 -000 Xxxxxxxx 3 Business 50 - 249
Issue Classification. In its notice of an Issue, the Client will reasonably classify for DevFactory the initial priority of the Issue. Client will use the nature of the Issue and Client's business situation to initially classify each Issue. Client will classify each Issue in accordance with the severity classification table below. To the extent that DevFactory disagrees with any Issue classification provided by Client, DevFactory will promptly advise Client of the revised classification of any Issue.
Issue Classification. Issues are classified and defined in the following table: P1 / Critical Any issue without a known commercially reasonable workaround that breaks or materially impacts performance of logins, authorizations, critical data flow, movement of money, registration or customer service operations; or Any issue that results in the complete outage of PayPal account administration or fraud management systems. P2 / Serious Any issue with a known commercially reasonable workaround that: • breaks or materially impacts performance of logins, authorizations, critical data flow, movement of money, registration or customer service operations; or • materially degrades other PayPal production payment services. or Any issue without a known commercially reasonable workaround that impairs other PayPal production Payment Services. P3 / Degraded Any issue with a known commercially reasonable workaround that minimally impairs PayPal production payment services. P4 / Minimal Any issue that does not impair PayPal production payment services.
Issue Classification. Supplier shall assign a priority level (Severity 1, Severity 2, or Severity 3) to each Issue, according to the criteria described in the following table; provided, however that ABA, at its option, may re-classify an Issue if deemed necessary by ABA. Severity 1 Services is unavailable for all Users or Services presents a disruption which has significant business Impact.
Issue Classification. Upon receipt of a support request, The Alliance, at its sole discretion, assigns a severity level to a support request according to the following criteria7: • Severity 1 – critical: an incident renders the Service unavailable and affects a large number of users in production; • Severity 2 – severe: a significant problem affecting a limited number of users in production and results in the Service being substantially non-functional or inoperative; • Severity 3 – medium: an error that causes errors, minor problems for users, or a heavy system load or results in a decrease in the performance in any functionality of the Service, but does not prevent the Subscriber from continuing to use the Service; • Severity 4 – minor: an error that results in the Service operating or performing other than as described in the Documentation, but which does not have a material adverse effect on the performance of the Service. This includes issues with a specific Testcase or Testcase group. • Severity 5 – low: a deficiency that causes minor problems or inconvenience to users and includes improvements to the Service
