Support Requests & Case Severity
This article describes how support requests are tracked, how severity levels are defined, and what response commitments apply to each level.
Support Requests
Case Numbers
When a support request is opened, it is tracked as a "case." Each specific question or problem is tracked as a separate case and assigned a unique case number. You will receive this case number after a support request is logged in the Capacity Private Cloud case tracking system. Please reference this number in all future correspondence with Technical Support relating to the case.
Case Severity Levels
To prioritize the handling of support requests, a severity scale of 1–4 is used. Each support request must be assigned a severity level. The table below provides descriptions and symptoms to help determine the correct level.
| Severity | Summary | Detailed Description | Symptoms |
| 1 – Critical | Production system is down or unusable. | A production system is down or severely impaired to the point where it is unusable. Errors causing a production outage that cannot be resolved by a restart or workaround. A critical error or failure in the operation of the platform that results in a major or total failure to perform substantially in accordance with its specification, causing a major or total interruption to business operations. | Supported product totally inoperative. Corruption or destruction of data. Catastrophic failures (50% or greater degradation of service). Degraded performance (throughput/response) such that the product is not usable in production (50% or greater degradation of service). |
| 2 – Major | Production system is impaired but usable. | A high-impact error where the supported product is operating in a significantly impaired fashion or a major function is unusable. Cannot be resolved by a restart or workaround, but the customer is able to run in production. | Supported product running with repeated interruptions. Degraded performance (throughput/response) with severe impact on use, including intermittent errors. Time-sensitive error important to long-term productivity, not causing an immediate stoppage of work. |
| 3 – Minor | Error in production that does not qualify as Severity 1 or 2, or any error in a non-production system. | Errors without significant impact on production. Errors that can be resolved by a restart or workaround. Any issue originally reported as Severity 1 or 2 that has been temporarily resolved with a workaround will be reduced to Severity 3, provided there is no remaining significant impact to production use. | Non-critical errors. Non-critical degradation in performance (throughput/response). Intermittent errors with low or no impact on customer operations. Errors in test, development, or other non-production systems. |
| 4 – Other | Any issue not meeting the criteria for Severity 1, 2, or 3. | Errors that do not affect use of the supported product. New feature requests. | Cosmetic issues. Errors in documentation. Development-related support that does not impact project schedule. |
Response Times by Severity
Response times are based on your contractual service level agreement and the severity of the issue. The table below outlines the relationship between severity level, response commitment, and resolution approach.
| Severity | Support Response | Resolution Goals | Resolution Method |
| 1 – Critical | Initial response: 1 hour Hours: 8am – 1am GMT, Mon–Fri Resources: Dedicated continuously until resolved. Progress updates: Every 4 hours. | Resolution target: 24 hours | Error correction |
| 2 – Major | Initial response: 4 hours Hours: 8am – 1am GMT, Mon–Fri Resources: Dedicated continuously during business hours until resolved. Progress updates: Daily. | Resolution target: 48 hours | Error correction |
| 3 – Minor | Initial response: 8 hours (within one business day) Hours: 8am – 1am GMT, Mon–Fri Resources: As needed during business hours. Progress updates: Upon determined path to resolution, and upon actual resolution. | Resolution target: Next minor or major release | Update |
| 4 – Other | Initial response: 24 hours (within three business days) Hours: 8am – 1am GMT, Mon–Fri Resources: As needed during business hours. Progress updates: Upon determined path to resolution, and upon actual resolution. | Resolution target: To be determined based on development priorities and scheduling. | Update, at Capacity's discretion |
Remote Access
As part of providing technical support, Technical Support may request remote access to relevant machines, as this is frequently the most expedient way to resolve issues.
The preferred method for remote access is direct Secure Shell (SSH) on Linux or Remote Desktop Protocol (RDP) on Windows. We recommend configuring firewalls to allow direct SSH or RDP access.
If those options are not available, Technical Support may ask to schedule a Zoom, Google Meet, Teams or WebEx session in which you share control of your desktop. At the discretion of Technical Support, other remote access methods (such as VPN) may also be used based on your preference. Please contact Technical Support with any questions about remote access options.