Legal Information
Service Level Agreement for the gro.now Platform (b2b)
Version v.1.0 dated 23.10.2025
1. General Provisions
1.1.
This Service Level Agreement (SLA) establishes the quality, availability, and support metrics for the gro.now Platform, as well as the procedure for providing service credits in case of their violation.
1.2. - 1.5.
1.2. This SLA is an integral part of the User Agreement (b2b) and applies to all Clients with an active Subscription. Terms are used in the meanings defined in the User Agreement.
1.3. The SLA governs:
(i) the availability and stability of the Platform;
(ii) the classification and handling of incidents;
(iii) the procedure for interacting with the support service;
(iv) the conditions for calculating and providing service credits.
1.4. The SLA does not apply to trial, test, and beta versions, additional services outside the tariff plan, or to failures caused by the Client's actions, external services, or circumstances beyond the Provider's control.
1.5. The Provider monitors the status of the Platform, records incidents, and publishes availability reports. In disputed cases, the Provider's data shall prevail unless the Client provides reliable counter-evidence.
1.3. The SLA governs:
(i) the availability and stability of the Platform;
(ii) the classification and handling of incidents;
(iii) the procedure for interacting with the support service;
(iv) the conditions for calculating and providing service credits.
1.4. The SLA does not apply to trial, test, and beta versions, additional services outside the tariff plan, or to failures caused by the Client's actions, external services, or circumstances beyond the Provider's control.
1.5. The Provider monitors the status of the Platform, records incidents, and publishes availability reports. In disputed cases, the Provider's data shall prevail unless the Client provides reliable counter-evidence.
2. Key Concepts
2.1. - 2.21.
- 2.1. Platform – the set of gro.now software and technical means provided by the Provider on a SaaS model, ensuring Client access to functionality and data in accordance with the User Agreement.
- 2.2. Services – the functions and capabilities of the Platform that ensure the Provider's fulfillment of its obligations regarding availability, support, and updates within the Client's current Tariff Plan.
- 2.3. Availability (Uptime) — the percentage of time in a billing period during which the Platform is functioning normally and allows for the performance of key user operations.
- 2.4. Downtime — a period of unavailability of the Platform or significant limitation of its functions, confirmed by the Provider's system monitoring.
- 2.5. Excluded Downtime – periods of unavailability not included in the availability calculation (including scheduled and emergency maintenance, force majeure, failures of external services, or Client actions).
- 2.6. Incident – a confirmed event affecting the availability, performance, security, or integrity of the Platform and requiring the intervention of the Provider's specialists.
- 2.7. Incident Category – the severity level of an incident, determined by the degree of impact on Clients and Platform functions.
- 2.8. Scheduled Maintenance – pre-planned technical operations for updating, backing up, or modernizing the Platform, of which Clients are notified in advance.
- 2.9. Emergency Maintenance – technical actions by the Provider necessary to prevent or eliminate a critical failure, security threat, or violation of the law, carried out without prior notice with subsequent information provided to Clients.
- 2.10. Time to Acknowledge (TTA) – the period between the registration of an incident and the start of its processing by a Provider's specialist.
- 2.11. Time to Restore Service (TTRS) – the period required to restore the normal operation of the Platform after an incident.
- 2.12. Service Credit – compensation in the form of a credit (discount) in future payments for the Client's Subscription, provided when the Provider fails to meet the target SLA metrics.
- 2.13. Monitoring — the set of automated tools and processes of the Provider that ensure continuous observation of the Platform's status, registration of incidents, and recording of downtime.
- 2.14. Support — the process of interaction between the Client and the Provider on issues of incidents, requests, notifications, and technical support, including the registration of tickets and feedback through established channels.
- 2.15. Billing Period – a calendar month used for measuring availability, classifying incidents, and providing service credits.
- 2.16. Client – a legal entity or individual entrepreneur with an active Subscription using the Platform's Services.
- 2.17. Support Business Hours — the period during which the Provider's employees accept and process Client requests through the established support channels.
- 2.18. Business Days – working days according to the production calendar for the current year, approved by the Ministry of Labor and Social Protection of the Population of the Republic of Kazakhstan.
- 2.19. Incident Report (RCA) – a document containing a description of the incident, its impact, root cause, measures taken, and corrective actions.
- 2.20. Workaround – a temporary measure or configuration change that allows for the reduction of an incident's impact to an acceptable level until a final fix is implemented.
- 2.21. AUP - the Acceptable Use Policy, located at https://app.gro.now/legal/acceptable-use-policy, which defines prohibitions and restrictions when using the Platform.
3. Target Metrics and Measurement Methodology
Metrics Table
| Metric | Target Value | Measurement Method | Comments / Exclusions |
|---|---|---|---|
| Availability (Uptime) | ≥ 95% per Billing Period | Provider's monitoring. Unavailability intervals of more than 5 min are considered. | Scheduled and emergency maintenance, external failures, Client actions, force majeure, trial/beta environments are not included. |
| Billing Period | Calendar month (UTC+5) | Continuous monitoring is maintained | Uptime = 1 - (Downtime / Period Time). |
| Scheduled Maintenance | Notification ≥ 24 hours in advance; total ≤ 4 hours per month | According to the Provider's schedule and notifications | Performed mainly between 02:00–06:00 (UTC+5). See Section 9 for details. |
4. Incident Classification, Response and Recovery Time
| Category (Priority) | Description | Typical Impact | Example Situations | Target Times (Response / Recovery) |
|---|---|---|---|---|
| P1 - Critical | Complete unavailability of the Platform or its key functions. | Most Clients cannot use the service. | Platform does not load; API does not respond; critical operations fail. | Response (TTA) – up to 1 hr (24x7) Recovery (TTRS) – up to 4 hrs |
| P2 – High | Significant degradation or limitation of key modules. | Substantial performance degradation or limited access for some users. | Errors when loading projects, failures of analytical modules, mass timeouts. | Response (TTA) – up to 2 hrs Recovery (TTRS) – up to 8 hrs |
| P3 – Medium | Failure of individual functions that do not critically affect the main functions of the Platform. | Operation of individual components or operations is disrupted. | Interface errors, incorrect reports, notification failures. | Response (TTA) – up to 4 hrs Recovery (TTRS) – up to 24 hrs |
| P4 – Low | Non-critical defects or enhancement requests. | Minimal impact, the service is operational. | Inaccuracy in the interface, request for configuration or documentation. | Response (TTA) – up to 1 business day Fix – according to the release plan |
5. Support and Contact Procedure
5.1. - 5.9.
5.1. The Provider provides technical support to Clients on issues of availability, incidents, configuration, and operation of the Platform within the current Tariff Plan.
5.2. Support is provided through the following channels: (i) a ticket system in the Platform's interface (if available); (ii) e-mail: support@gro.now; (iii) a feedback form on the website or in the personal account.
5.3. A Client's request must contain: (i) the account identifier and contact person; (ii) a description of the problem, the supposed incident category; (iii) technical details (date, time, screenshots, logs, URL, or task ID).
5.4. All requests are registered with a ticket number and incident category assigned. The Provider informs the Client about the start of processing and the further progress of the resolution.
5.5. For P1 category incidents, support is provided 24x7. For other categories – during support business hours: 09:00-19:00 (UTC+5) on business days.
5.6. The Client undertakes to ensure the availability of the contact person and, if necessary, to provide additional information or test data to reproduce the incident.
5.7. Upon receiving notification of an incident's resolution, the Client confirms its closure or reports the need for additional verification.
5.8. If a similar problem reoccurs within 7 calendar days, the Client has the right to request an Incident Report (RCA). The Provider provides it within 5 business days after the service is stabilized.
5.9. If an incident is caused by the actions of the Client, its users, contractors, or third-party services, the Provider has the right to classify the request as a consultation and process it within the framework of regular support without applying SLA deadlines.
5.2. Support is provided through the following channels: (i) a ticket system in the Platform's interface (if available); (ii) e-mail: support@gro.now; (iii) a feedback form on the website or in the personal account.
5.3. A Client's request must contain: (i) the account identifier and contact person; (ii) a description of the problem, the supposed incident category; (iii) technical details (date, time, screenshots, logs, URL, or task ID).
5.4. All requests are registered with a ticket number and incident category assigned. The Provider informs the Client about the start of processing and the further progress of the resolution.
5.5. For P1 category incidents, support is provided 24x7. For other categories – during support business hours: 09:00-19:00 (UTC+5) on business days.
5.6. The Client undertakes to ensure the availability of the contact person and, if necessary, to provide additional information or test data to reproduce the incident.
5.7. Upon receiving notification of an incident's resolution, the Client confirms its closure or reports the need for additional verification.
5.8. If a similar problem reoccurs within 7 calendar days, the Client has the right to request an Incident Report (RCA). The Provider provides it within 5 business days after the service is stabilized.
5.9. If an incident is caused by the actions of the Client, its users, contractors, or third-party services, the Provider has the right to classify the request as a consultation and process it within the framework of regular support without applying SLA deadlines.
6. Exclusions from Availability Calculation
6.1.
Periods when unavailability or failures are caused by circumstances beyond the Provider's control are excluded from the calculation of SLA metrics.
6.2. Such cases include:
a) scheduled and emergency technical maintenance, carried out in compliance with the notification procedure;
b) incidents caused by the actions or settings of the Client, its users, or contractors;
c) failures and delays in the operation of external integrations, communication networks, cloud, or third-party payment services;
d) violations of the AUP or exceeding limits/quotas;
e) incidents in trial, demo, or beta environments;
f) the Client's refusal of a proposed workaround;
g) requirements of government authorities, legal restrictions, or regulatory measures;
h) force majeure.
b) incidents caused by the actions or settings of the Client, its users, or contractors;
c) failures and delays in the operation of external integrations, communication networks, cloud, or third-party payment services;
d) violations of the AUP or exceeding limits/quotas;
e) incidents in trial, demo, or beta environments;
f) the Client's refusal of a proposed workaround;
g) requirements of government authorities, legal restrictions, or regulatory measures;
h) force majeure.
6.3. - 6.4.
6.3. Such periods are recorded by the Provider as 'excluded intervals' and are not taken into account when calculating Uptime. The decision to apply an exclusion is documented in the incident report.
6.4. Open Sources and Parsing. The availability and composition of data from open sources depend on the owners of the respective platforms (including their rules, robots.txt, API policies, anti-bot mechanisms, captchas, and limits). The Provider does not guarantee the continuous operation of parsers/connectors to specific sources and reserves the right to:
a) temporarily suspend or terminate collection from a source;
b) not restore the operation of a specific parser if the source owner has restricted access, changed the policy/format, or if it is disproportionate to the risks/costs;
c) replace the source with a functionally equivalent or similar one in value. Such events are not considered a violation of the SLA and do not entail service credits.
6.4. Open Sources and Parsing. The availability and composition of data from open sources depend on the owners of the respective platforms (including their rules, robots.txt, API policies, anti-bot mechanisms, captchas, and limits). The Provider does not guarantee the continuous operation of parsers/connectors to specific sources and reserves the right to:
a) temporarily suspend or terminate collection from a source;
b) not restore the operation of a specific parser if the source owner has restricted access, changed the policy/format, or if it is disproportionate to the risks/costs;
c) replace the source with a functionally equivalent or similar one in value. Such events are not considered a violation of the SLA and do not entail service credits.
7. Availability Calculation Methodology (Uptime Formula)
7.1. - 7.9.
- 7.1. Billing Period – a calendar month in the Provider's time zone (UTC+5).
- 7.2. Uptime reflects the percentage of time during which the Platform was functioning normally, without confirmed unavailability incidents, excluding 'excluded intervals'.
- 7.3. Calculation Formula: Availability = (1 - Td / (Tt - Te)) x 100% where:
- Td - the total duration of confirmed unavailability periods (Downtime), expressed in minutes;
- Tt - the total time of the billing period;
- Te - the total duration of excluded intervals, as defined in Section 6.
- 7.4. Only confirmed unavailability incidents lasting at least 5 consecutive minutes and affecting key user operations are included in the calculation. Short-term interruptions not recorded by the Provider's monitoring or not confirmed by the Client with supporting data are not taken into account.
- 7.5. Monitoring is carried out at the application layer (availability of interfaces, key services). Network failures or access errors on the part of the Client's infrastructure, local communication providers, or third-party integrations are not included in the calculation.
- 7.6. When conducting scheduled or emergency maintenance, the Provider specifies the specific window and duration, which is excluded from the calculation time.
- 7.7. The final Uptime figure is rounded to two decimal places and is recorded in the Provider's monthly report.
- 7.8. In case of disputed calculations, the data from the Provider's system monitoring shall prevail, unless the Client provides reliable and confirmed metrics of a comparable level of accuracy.
- 7.9. If errors are found in the calculations, the Provider shall correct the reporting and, if necessary, recalculate the service credits in the next billing period.
8. Service Credits and Provision Procedure
8.1. A Service Credit is a form of compensation to the Client for failing to achieve the target availability metrics, expressed as a discount applied to the payment for subsequent Subscription billing periods. No monetary payments are made.
8.2. The amount of the service credit is determined based on the actual availability (Uptime) for the billing month according to the Provider's monitoring data:
8.3. The credit is provided upon the Client's written request, sent within 15 calendar days after the end of the billing month. The request must contain a justification and, if necessary, confirmation of incidents (ticket IDs or event dates).
8.4. The credit is applied to the payment for the next Subscription period, or, if the Subscription is terminated, as a set-off against the final settlements between the Parties.
8.5. Credits are not provided if:
a) the unavailability occurred during periods excluded from the calculation according to Section 6;
b) the Client failed to fulfill its obligations to provide information for the incident investigation;
c) the unavailability is related to the actions of the Client, its users, or contractors;
d) the incident was not registered or confirmed in the Provider's support system.
8.6. Service credits are the sole and exclusive remedy of the Client for SLA violations and are not cumulative with other claims for damages, penalties, or fines, unless otherwise provided for in an individual agreement between the Parties.
8.7. The provision of a service credit does not release the Provider from the obligation to eliminate the causes of the incident and take measures to prevent its recurrence.
8.2. The amount of the service credit is determined based on the actual availability (Uptime) for the billing month according to the Provider's monitoring data:
| Actual Uptime for the month | Service Credit Amount |
|---|---|
| from 95.0% to 97.99% | 5% of the monthly Subscription fee |
| from 90.0% to 94.99% | 10% of the monthly Subscription fee |
| below 90.0% | 20% of the monthly Subscription fee |
8.3. The credit is provided upon the Client's written request, sent within 15 calendar days after the end of the billing month. The request must contain a justification and, if necessary, confirmation of incidents (ticket IDs or event dates).
8.4. The credit is applied to the payment for the next Subscription period, or, if the Subscription is terminated, as a set-off against the final settlements between the Parties.
8.5. Credits are not provided if:
a) the unavailability occurred during periods excluded from the calculation according to Section 6;
b) the Client failed to fulfill its obligations to provide information for the incident investigation;
c) the unavailability is related to the actions of the Client, its users, or contractors;
d) the incident was not registered or confirmed in the Provider's support system.
8.6. Service credits are the sole and exclusive remedy of the Client for SLA violations and are not cumulative with other claims for damages, penalties, or fines, unless otherwise provided for in an individual agreement between the Parties.
8.7. The provision of a service credit does not release the Provider from the obligation to eliminate the causes of the incident and take measures to prevent its recurrence.
9. Scheduled and Emergency Maintenance
- 9.1. Scheduled Maintenance. Conducted mainly between 02:00–06:00 (UTC+5). The Provider notifies the Client at least 24 hours in advance, indicating the date, window, and affected functions. The time of scheduled maintenance is considered an excluded interval and is not included in the Uptime calculation.
- 9.2. Emergency Maintenance. Performed without prior notice if necessary to prevent/eliminate a critical incident or security vulnerability. The Provider posts a subsequent notification with key details and the actual duration of the window; such intervals are excluded from the Uptime calculation.
- 9.3. Changes without Impact. Brief technical/clarifying changes to the configuration and infrastructure that do not affect the Client's rights and the Platform's availability may be performed immediately and without notification.
- 9.4. Rollback of Changes. In case of a negative impact of a release, the Provider has the right to roll back the changes or apply a workaround until a full fix is implemented.
- 9.5. Communications. Information about the status of work and incidents is published through the status page/Platform interface and/or sent to the contact e-mail addresses of the Client's administrators.
- 9.6. Rescheduling and 'Blackout Dates'. The Provider, where possible, takes into account periods critical for the Client (based on advance notifications) and may reschedule the maintenance window if it is compatible with security and the release schedule.
- 9.7. Client's Obligations. The Client ensures that unsaved data is saved before the start of the maintenance window, correctly completes active operations/integration tasks, and refrains from launching long-running tasks during the technical window.
10. Liability and Limitations
10.1. - 10.7.
10.1. The Provider is responsible for complying with the target SLA metrics within its area of control, as defined by this document and the User Agreement.
10.2. The Provider is not responsible for failures, delays, and other consequences caused by:
a) the acts or omissions of the Client, its users, or contractors;
b) malfunction of equipment, networks, or software outside the Provider's control;
c) restrictions imposed by the owners of external sources, platforms, or APIs, including changes in data formats and access policies;
d) force majeure circumstances or actions of government authorities.
10.3. The Provider's aggregate liability for all claims related to SLA violations is limited to the amount of service credits provided for in Section 7 and cannot exceed the Client's monthly fee for the corresponding billing period.
10.4. The Provider is not liable for:
a) lost profits, loss of data, or reputational damage;
b) indirect, incidental, or consequential damages, even if notified of the possibility of their occurrence;
c) the Client's refusal of a proposed workaround.
10.5. Service credits are the sole and exclusive remedy of the Client for SLA violations. The Client is not entitled to claim other forms of compensation or penalties, unless otherwise established by a written agreement between the Parties.
10.6. The Provider has the right to temporarily restrict the Client's access to the Platform in case of a violation of the AUP, a security threat, exceeding of limits, or other risks affecting the stability of the system. Such measures are not considered a violation of the SLA.
10.7. The Provider undertakes to make a good faith effort to eliminate the causes of incidents and to take reasonable measures to prevent their recurrence, including updates, architectural improvements, and process audits.
10.2. The Provider is not responsible for failures, delays, and other consequences caused by:
a) the acts or omissions of the Client, its users, or contractors;
b) malfunction of equipment, networks, or software outside the Provider's control;
c) restrictions imposed by the owners of external sources, platforms, or APIs, including changes in data formats and access policies;
d) force majeure circumstances or actions of government authorities.
10.3. The Provider's aggregate liability for all claims related to SLA violations is limited to the amount of service credits provided for in Section 7 and cannot exceed the Client's monthly fee for the corresponding billing period.
10.4. The Provider is not liable for:
a) lost profits, loss of data, or reputational damage;
b) indirect, incidental, or consequential damages, even if notified of the possibility of their occurrence;
c) the Client's refusal of a proposed workaround.
10.5. Service credits are the sole and exclusive remedy of the Client for SLA violations. The Client is not entitled to claim other forms of compensation or penalties, unless otherwise established by a written agreement between the Parties.
10.6. The Provider has the right to temporarily restrict the Client's access to the Platform in case of a violation of the AUP, a security threat, exceeding of limits, or other risks affecting the stability of the system. Such measures are not considered a violation of the SLA.
10.7. The Provider undertakes to make a good faith effort to eliminate the causes of incidents and to take reasonable measures to prevent their recurrence, including updates, architectural improvements, and process audits.
11. SLA Updates and Entry into Force
11.1. The Provider has the right to make changes to this SLA to clarify terms, metrics, procedures, as well as when changing the technical architecture or service model of the Platform.
11.2. The new version of the SLA is published on the website https://app.gro.now/legal/sla and comes into force:
(i) 5 calendar days after publication – by default;
(ii) in a shorter period, if specified in the notification and due to the need for an urgent update of the conditions;
(iii) immediately – if the changes are of a technical or clarifying nature and do not affect the Client's rights.
11.3. The changes apply to new and current Subscriptions, starting from the next billing period, unless otherwise expressly stated in the notification.
11.4. The Client is considered notified of the changes from the moment the new version of the SLA is published on the Provider's website. Continued use of the Platform after the changes come into force means the Client's agreement with the updated version.
11.5. In case of disagreement, the Client has the right to terminate the use of the Platform in the manner provided for by the User Agreement.
11.6. This version of the SLA comes into force from the date of its publication and is valid until replaced by a new version.
11.2. The new version of the SLA is published on the website https://app.gro.now/legal/sla and comes into force:
(i) 5 calendar days after publication – by default;
(ii) in a shorter period, if specified in the notification and due to the need for an urgent update of the conditions;
(iii) immediately – if the changes are of a technical or clarifying nature and do not affect the Client's rights.
11.3. The changes apply to new and current Subscriptions, starting from the next billing period, unless otherwise expressly stated in the notification.
11.4. The Client is considered notified of the changes from the moment the new version of the SLA is published on the Provider's website. Continued use of the Platform after the changes come into force means the Client's agreement with the updated version.
11.5. In case of disagreement, the Client has the right to terminate the use of the Platform in the manner provided for by the User Agreement.
11.6. This version of the SLA comes into force from the date of its publication and is valid until replaced by a new version.