Severity Level Sample Clauses

Severity Level. Two (2) Response Time:

Severity Level. The level of bugs/Issue/Incident that prevent the Software for doing what is supposed to do.

Severity Level. Two (2) a) Failure of any complete Alarm portions/area b) Unstable power supply to the equipment/system c) Partial failure of remote alarm button d) Intermittent keypad button failure e) Failure of a single zone component and whose coverage can be complemented by other zone xxxxxxxxx.xx faulty detector, Magnetic contact, vibration sensor etc f) Faulty flasher g) Intermittent component failure eg detector, panic buttons etc a) The Contractor will respond within Twelve hours (12hr) of the initial service call for support being received by the Contractor. b) Standby back-up services to be on site within 5minutes of reported failure and camp until system restoration.

Severity Level. 8.1 Upon receipt of a properly submitted Ticket, the Supplier shall agree the Incident Severity Level jointly with the Client according to the guidelines defined below. Severity Level may be re-evaluated upon submission of a Workaround. Severity Level 1 is defined as a critical problem that impacts the Client’s ability to deliver the Software or the services that the Software enables. the Client’s critical production systems experience a total loss of the service provided or enabled by the Software. Severity Level 2 is defined as a major problem that impacts the Client’s ability to deliver the Software or the services that the Software enables. the Client’s business production systems experience significant loss or degradation of the service provided or enabled by the Software. Severity Level 3 is defined as a minor problem that does not impact the Client’s ability to deliver the Software or the services that the Software enables. the Client’s business production systems do not experience any loss or degradation of the service provided or enabled by the Software. Severity Level 4 is defined as all other problems related to the Software or the services that the Software enables.

Severity Level. Severity Level Description

Severity Level. Two (2) a) Failure of more than 2 zones/detectors, sounder/flasher, Fire exit door, sections of hydrant system etc. b) Failure of any complete sub-system /floor/fire exit doors system, module, repeater etc. c) Failure of any complete sub-system/section which does not affect more than 50% of the system. The Contractor will respond within Twelve hours (12hr) of the initial service call for support being received by the Contractor.

Severity Level. The Service Request severity level is based on the following severity definitions: (i) Critical: End- Customer experiences a complete loss of service in the Production Environment. Work cannot reasonably continue, the operation is mission critical to the business and the situation is an emergency. A Critical Service Request has one or more of the following characteristics: (a) corrupted data or applications; (b) a critical documented function is not available; (c) system hangs indefinitely, causing unacceptable or indefinite delays for resources or response; (d) system crashes, and crashes repeatedly after reset attempts; (ii) Urgent: End-Customer experiences a severe loss of service. No acceptable Workaround is available. However, operation can continue in a restricted fashion. (iii) Normal: End-Customer experiences a minor loss of service. The impact is an inconvenience, which may require a Workaround to restore functionality; (iv) Low Priority: End-Customer experiences no loss of service. The result does not impede the operation of a system. End- Customer’s technical contacts are requested to propose this classification with great care, so that Problems receive the appropriate resource allocation from OutSystems. OutSystems reserves the right to modify the severity level of a Service Request following reasonable evaluation of the same.

Severity Level. The LICENSEE is required to provide the severity level of the help ticket request.

Severity Level. In order to establish the common understanding of the criticality of the fault / problems / bugs and to enable Argoid and the User to take action accordingly, the same are defined here below which shall be the base for categorizing the nature of faults / problems / bugs.

Severity Level. In the event of errors or issues that affect the availability of the TouchPoint software application, or significantly impact its capacity, capabilities, and/or operating functions, Cogent will take all necessary actions to resolve these issues and ensure the normal operation of the TouchPoint software, following the procedures and timelines outlined below. All changes and fixes will undergo thorough testing according to internal processes before being delivered. Software issues will be classified as follows: Severity Level Description Examples Outage (S1)  Complete loss of cloud SaaS services.  Production application is down or major malfunction resulting in the application inoperative condition  Issues causing a complete loss of service or critical business operations are halted  Application is not accessible  No user can log in Stopper (S2)  A critical problem rendering the system inoperable or unusable  High number of users unable to perform their normal functions in the application  Specific functionality is mission critical to the business which is not working as expected  Confidentiality or Privacy is breached  Customer data loss  Unable to print from application  Important workflows are not triggered as expected  Visitors cannot be checked in  Material Requests cannot be created Significant (S3)  A significant problem that makes the system operationally inconvenient  Something major is not working, but the system is still usable to an extent.  In general, the system is working normally except for a limited portion.  Application slowness  Missing or incorrect reports  Problem affecting single user access to systems. Minimal (S4)  The system is still fully usable with limitations or workarounds.  A minor problem or inconvenience that does not reduce the system’s  Suboptimal software behavior without affecting functional integrity  Minimal performance degradation  Error message with workaround operational capacity and for which a workaround is available. Information (S5)  This request is about something with no system impact. This includes things like feature requests, general inquiries, etc.  How-to requests, clarifications, etc.  Requests for advice on product usage  Clarification on product documentation  Product enhancement request