1. Eligibility — expressly purchased SLA coverage only
1.1This SLA applies only where Customer has purchased a plan or service package that expressly includes SLA coverage and that entitlement is specifically recorded in Customer’s accepted order or written service agreement. A paid platform subscription, token purchase, access to support or publication of this SLA does not by itself include SLA coverage. The recorded entitlement identifies the covered Services and coverage term. Unless that order or agreement specifies a different agreed schedule, the availability, response, progress-update and credit provisions below apply only to those covered Services during that term.
1.2Customers without that express purchased entitlement are not entitled under this SLA to the stated availability percentage, response or update deadlines, continuous Critical-incident handling or service credits. Providing ordinary support or voluntarily assisting with an incident does not activate SLA coverage. The Company’s other express contractual commitments and mandatory legal obligations remain unaffected.
1.3The order identifies covered workspace, API, orchestration and execution components. A general reference to the platform does not exclude its contracted core function merely because that function uses an AI provider. Trials, previews, custom development and Customer-Connected Services are excluded unless expressly listed as covered.
1.4The order identifies covered production components and any departures from the default schedule below. Core Services include the purchased workspace, permission administration, activity records and Company-operated workflow orchestration. Independent Customer-Connected Services and the correctness of model content are outside the availability metric. Company-operated core functionality is not excluded solely because it depends on a Company-appointed supplier.
2. Availability measurement
2.1Availability is calculated separately for each covered component over a calendar month as: 100 × (eligible minutes minus unavailable minutes) ÷ eligible minutes. Eligible minutes are the minutes in the measurement period less only the exclusions permitted by this SLA. If there are no eligible minutes, no availability percentage is calculated for that component.
2.2Unavailable time means a material inability to use the covered component for its contracted purpose, supported by monitoring or other reasonable evidence. A dashboard that loads does not establish availability of a covered execution API. An inaccurate model response alone is not downtime; a technical failure that prevents the covered service from processing eligible requests may be.
2.3Partial failures count according to the affected component and scope. Overlapping incidents must not be counted twice. Company monitoring is the primary measurement source, but Customer may supply timestamped request identifiers and other credible evidence for review. No party’s logs are conclusive where a material inconsistency is demonstrated.
2.4Measurement covers only the portion of the calendar month during which the relevant component is contractually covered. The schedule’s measurement time zone applies; if none is specified, Israel time (Asia/Jerusalem) applies. Qualifying unavailability starts when supported evidence shows the relevant failure began and ends when the covered function is restored, including through a reasonable workaround that materially restores its contracted use. A ticket’s submission time does not itself determine the start of downtime. The schedule must define how a partial outage affects the metric; Company may not retrospectively introduce a weighting method that reduces an accrued claim.
2.5The default monthly availability target is 99.5% for covered Core Services. A partial failure counts as unavailability for the affected covered component when it materially prevents its contracted use; its fee allocation must be agreed before coverage begins. This target concerns technical service availability, not the factual accuracy or commercial outcome of an Agent’s work.
3. Maintenance and exclusions
3.1Planned maintenance is excluded only within the notice, timing and duration allowances in the applicable order. Emergency work reasonably necessary to address an imminent security or stability risk may begin sooner, with notice as practicable. Routine changes cannot be labelled emergency maintenance solely to avoid measurement.
3.2Failures caused by Customer’s unsupported configuration, breach, local connectivity, disabled credentials or independent provider account are excluded only to the extent they cause the relevant unavailability. Company remains responsible for the contracted scope and its own configuration. Company-selected hosting or model infrastructure is not automatically excluded merely because it is external.
3.3Provider moderation of a prohibited request, agreed quota enforcement and a valid suspension under the Terms do not constitute unavailability of an otherwise working service. An erroneous Company block or incorrect quota implementation must be assessed on its actual effect. Any force-majeure exclusion follows the Terms and the express SLA scope.
3.4Emergency maintenance does not automatically qualify as excluded time: its treatment follows the expressly agreed exclusion, limited to the period reasonably necessary to address the qualifying risk. If the order grants no maintenance exclusion, otherwise qualifying unavailability during maintenance remains included in measurement. Exclusions apply only for their demonstrated duration and causal effect and do not excuse a separate breach of an express security or data-protection obligation.
4. Support channels and service hours
4.1For Customers eligible under Section 1, SLA support is provided by email only. Submit service tickets to support@uniforce.work from an authorized account contact, identifying the workspace, affected function, occurrence time and time zone, impact and relevant request identifiers or safe reproduction steps. Do not send passwords or API secrets. Replies on the existing email thread preserve the incident history. Telephone, WhatsApp, live chat and remote-screen support are not included.
4.2Business Hours are Sunday through Thursday, 09:00–18:00 Israel time (Asia/Jerusalem), excluding Israeli public holidays and holiday eves. First-response targets count only these hours; tickets received outside them enter the response clock at the next opening. A business day is nine Business Hours for calculating these targets.
4.3Once a Critical incident has been acknowledged and classified, Company will continue handling it around the clock until core service is restored or a reasonable workaround is provided. This continuous incident handling does not promise a 24/7 first-response email desk. Security incidents should also be sent to security@uniforce.work; mandatory incident duties are unaffected by support hours.
5. Severity and prioritization
5.1Company and Customer will assess severity from actual business impact and available workarounds. Customer must identify a contact able to assist with diagnosis. Company may change severity when the impact changes and will explain a disputed classification. A high volume of duplicate tickets does not raise severity.
| Priority | Impact | First substantive response | Progress updates |
|---|---|---|---|
| Critical | Core production service unavailable; no reasonable workaround. | Within 2 Business Hours. | Every 4 elapsed hours while actively handled, until restoration or workaround. |
| High | Material impairment of an important production function. | Within 4 Business Hours. | Every business day while unresolved and actively investigated. |
| Medium | Partial failure with a reasonable workaround. | Within 2 business days. | Every 3 business days while actively investigated. |
| Low | Minor defect or ordinary technical question. | Within 3 business days. | Every 5 business days while actively investigated. |
| Service request | Configuration guidance or improvement request. | Within 5 business days. | A next step or assessment date in the response; no feature-delivery commitment. |
6. Response, restoration and resolution
6.1An initial response is an acknowledgement by support with a next step or request for relevant information. It is different from restoring service and from permanently resolving the underlying defect. A workaround can restore a usable service while permanent remediation continues.
6.2Investigation may depend on access to diagnostic information, Customer cooperation or an external provider. We will identify material dependencies and use reasonable efforts to progress work within our control. A paused diagnostic step does not automatically remove otherwise qualifying downtime from availability measurement.
6.3Restoration objectives, backup recovery-point objectives and guaranteed resolution times apply only when expressly included in the order. Uptime, data durability and correctness of business decisions are separate commitments; none should be inferred from another.
6.4A response clock begins when the designated support channel receives a report sufficient to identify the affected account, covered component and material impact, and runs only during the purchased coverage hours. Missing information not reasonably necessary to identify the incident does not postpone that start. An automated receipt alone is not an initial response. Duplicate reports of the same incident do not restart the clock. A severity change must be supported by the incident’s actual impact and does not erase a response deadline already missed.
6.5Progress-update intervals are status communication targets, not guaranteed resolution periods. An update may describe completed investigation, an external dependency, a workaround or the next step. Company will explain any period awaiting necessary Customer information; such a dependency does not erase an already missed response target or otherwise qualifying downtime.
7. Customer cooperation and safe recovery
7.1Customer must preserve relevant records, avoid repeated harmful retries, provide accurate impact information and test a proposed workaround where reasonably practicable. Customer should pause affected autonomous workflows where continued execution could cause duplicate messages, transactions or charges.
7.2Following restoration, Customer remains responsible for deciding whether to resume its business workflows and reconciling external actions. Company will provide reasonably available information about the covered incident. Restoration does not automatically reverse transactions already accepted by an external service.
8. Service credits and claims
8.1Unless an accepted order specifies otherwise, availability credits use the table below and the recurring subscription fee allocated to the affected covered service for the relevant month. Taxes, usage-based model or communications charges, and professional services are excluded from that base. Credits are future service credits, not cash, and are not transferable. The default monthly ceiling is 45% of that fee base.
8.2Customer must submit a claim within 30 days after the affected month, identifying the incident, affected component, approximate duration and supporting evidence reasonably available to it. Company will review its measurements and the evidence, explain the outcome and apply an approved credit to a subsequent invoice or balance as specified in the order.
8.3The same interval is not credited twice. The highest applicable tier controls, subject to the 45% monthly ceiling unless an order states otherwise. No separate automatic monetary credit applies for a missed response or update target. Mandatory rights and an express termination refund remain unaffected.
8.4For fees prepaid over several months, the monthly credit base is the recurring fee allocated to the affected covered service divided by the number of months purchased, with an appropriate adjustment for a partial coverage month. Where services are bundled, the accepted order must state the allocation used for credits. Company must not assign that allocation retrospectively to reduce an accrued claim. Customer may submit a timely claim after expiry or termination for an incident during coverage. If no further invoice is due, an approved credit remains on the Customer account for a future eligible service purchase; it does not become cash or disappear solely because the subscription ended, subject to mandatory rights and any express termination refund.
| Monthly availability | Credit of eligible monthly subscription fee |
|---|---|
| 98% to below 99.5% | 5% |
| 85% to below 98% | 10% |
| Below 85% | 45% |
9. Persistent failure and other remedies
9.1The parties will review repeated material incidents and reasonable remediation steps. Where the failure amounts to a material breach of the Agreement, the cure and termination provisions in the Terms remain applicable unless a lawful, express negotiated provision states otherwise.
9.2The availability credit is the exclusive contractual monetary remedy for failure to meet the availability percentage itself. It does not extinguish unrelated confidentiality, data protection or security obligations, an express indemnity, material-breach termination rights, or rights that cannot lawfully be limited. Other contractual monetary claims remain subject to the Agreement’s liability limits.
10. Changes and contact
10.1Material reductions to an incorporated SLA apply prospectively at renewal unless Customer agrees otherwise or mandatory law requires a change. Operational improvements may be introduced during the term without reducing the contracted protection. The applicable order and accepted version identify Customer’s entitlement.
10.2Contact support@uniforce.work for service incidents and legal@uniforce.work for questions about the contractual schedule. An external provider’s public status page is useful diagnostic information, but is not itself an SLA granted by Company or a substitute for the agreed measurements.
10.3This SLA ends when the relevant covered Services end, except that measurement, timely claims, accrued credits and provisions necessary to resolve those claims survive. The Agreement’s order of precedence governs. This SLA controls only its expressly covered service-level subject matter; it does not replace the DPA, confidentiality obligations or the Agreement’s applicable liability provisions.