Incident Management

When an incident (an error or a system malfunction) occurs, the Administrator investigates what went wrong and assigns a priority level to it based on the impact and urgency of the failure or interruption. Each priority level is assigned a specific response time. If the incident is assigned the highest priority level (Сritical), the Administrator has to start working on resolving the incident immediately.

Having examined the incident, the Administrator starts to resolve it. After the incident has been resolved, the Administrator draws a conclusion on the cause behind the failure — whether it is a system error or a user error (by the Participant) — and make recommendations for preventing recurrence of such incidents in the future.

If the incident occurred due to the Participant’s fault, the Participant will be responsible for the costs incurred while resolving the incident.

Categories of urgency

Category Description
  • the system is in commercial operation and the service has been completely stopped or more than 30% of the system's performance has been lost for at least one hour due to an error within the system;
  • blockchain does not synchronize correctly and business-critical data is not provided correctly.
  • system operation is maintained, but the service is limited in functionality, performance, or time;
  • urgent (unscheduled) service maintenance by the Administrator’s technical support group is required;
  • normal system operation is impossible (see the “Critical” category), but a workaround that restores the system’s functionality has been developed;
  • the system is down (see the “Critical” category), but it is not in commercial operation.
  • the system is in beta testing;
  • system operation is maintained, but some rare errors occur (with a frequency of less than one error in 8 hours);
  • scheduled execution of a specific task by the Administrator’s technical support group is required;
  • the priority of the incident is high (see the “High” category), but a temporary alternative solution that restores system functionality has been found.
  • a failure in some non-critical operations that do not have a significant impact on the service providing for the Participant;
  • an additional feature request (see “Feature Request” under Types of Requests);
  • the urgency category is Medium (see the “Medium” category) and although the system’s behaviour complies with the intended functionality described in detail on, standards and generally accepted practice render the behaviour incorrect. A temporary alternative solution has been found.

Types of requests

When the system is in operation and incidents occur or there is a need for implementing new features, the Participant sends requests with a description of the issue to the Administrator to the following email address For each type of request, specific response time is set forth.

Type Description
Issue Some issues have arisen during system operation and assistance is required, except for situations covered by the “Service Request” and “Error” request types.
Feature Request A request for implementing a new feature into the system. This type of request implies that it is necessary to make changes to the system’s source code and documentation. It is also possible that the functionality specification needs to be supplemented.
Service Request

A request for system maintenance to be performed by the Administrator (maintenance):

  • install/update the system;
  • restore, transfer, or synchronize data;
  • put the system’s additional servers and modules into/out of operation;
  • make configuration changes for the main modules of the system.
ATTENTION! Maintenance is performed at an agreed upon time and according to a plan that was previously agreed upon as part of the request.

This type of request is determined by the Administrator. During the analysis of the system’s behaviour, a discrepancy between the real and claimed capabilities and/or an error in the software has been detected.

Note: the system’s capabilities are defined in the functional specification and official operation manuals.

Blockchain in Telecom Pre-ICO
Starts 20.01.2018
Meet us on event
Join the Bubbletone blockchain telecom ecosystem