SERVICE LEVEL AGREEMENT

Effective Date: 24 August 2026
Version: 2

This Service Level Agreement (SLA) forms part of the Terms of Service and must be read with the Privacy Policy, Customer Acceptable Use Policy, Suboperator List, Security and Incident Schedule, applicable Product and Processing Schedule and Online Order Record. Capitalised terms not defined here have the meanings given in the Terms of Service.

Henry's objective is dependable service and clear, practical support expectations.

Standard and Enterprise arrangements: The standard position described in this document applies unless a signed Enterprise Annex expressly varies an eligible, identified contractual matter. Where legally and operationally available, any enhanced or non-standard scope, service level, support, infrastructure, assurance, reporting, implementation or other commitment must be separately requested, assessed, approved and priced under the Enterprise Agreement. An Enterprise Annex cannot alter statutory rights or mandatory legal obligations.

1. Application and Scope

1.1. This SLA states the standard availability target, incident priorities, support-response targets, maintenance rules and service-credit remedy of Henry AI (Pty) Ltd, registration number 2023/620906/07, trading as Henry, Henry AI, Henry Ingest, Henry Insights and Henry Exchange (Henry), for a Tenant's covered paid production Services.

1.2. A Tenant receives this standard SLA while it has an active paid subscription, is current in payment, complies with the Agreement and uses a component expressly included in its plan.

1.3. This standard SLA excludes free plans, trials, demonstrations, proofs of concept, beta or experimental features and non-production environments.

1.4. The standard plan is designed around the component, response, recovery and credit commitments, and the incident-restoration efforts, stated below. It does not include dedicated infrastructure, customer-selected active-active architecture, customer-managed keys, immutable backups or a stricter product-specific objective.

2. Definitions

3. Covered Services

3.1. The Online Order Record and applicable Product Schedule identify the covered components. Unless stated otherwise, the following contracted production components are measured separately:

3.2. Coverage applies to each contracted component rather than to an isolated record, User, browser, device or output. A component is unavailable where its material contracted function cannot be completed or is degraded to the point that it is not materially usable, even if a login page or unrelated component remains reachable.

3.3. Henry's API and Native Integration component may be covered, but a Tenant's client, middleware, code, mapping, webhook endpoint, network, source system and downstream workflow are not. A provider event is excluded only under the narrower conditions in Section 5.1; use of a Henry-selected provider does not automatically remove the affected component from measurement.

3.4. A source-data error, inaccurate output, participant delay or finance outcome does not by itself constitute Downtime. A systemic Henry-controlled failure that prevents the contracted ingestion, extraction, query, export, routing or communication function from materially operating is measured as Downtime or degradation under Section 4.

3.5. Standard support focuses on the operation of the covered Service. Telephone and 24/7 support, on-site assistance, training, data cleansing, custom reports, migrations, project deadlines and professional services are not included. Privacy and security assurance is governed by the Privacy Policy Sections 7.4 and 7.5.

4. Availability

4.1. Henry's standard Monthly Availability commitment is 99.9% for each covered component during Business Hours. Availability outside Business Hours is not measured under the standard SLA.

Monthly Availability = ((total Business-Hours minutes in the calendar month − qualifying Downtime minutes during Business Hours) ÷ total Business-Hours minutes in the calendar month) × 100

4.2. Henry calculates Monthly Availability per component and calendar month using only minutes falling within Business Hours and identified synthetic monitoring, queue or job telemetry, API and application logs, provider evidence and incident records. Qualifying Downtime begins when reliable Henry monitoring or substantiated Tenant evidence shows material unavailability during Business Hours and ends when the component is restored, but only Business-Hours minutes count. An outage that begins outside Business Hours starts accruing qualifying Downtime only when Business Hours next begin and only if the component remains unavailable then. The Tenant may submit timestamps, errors, screenshots, request identifiers or independent monitoring; Henry will reconcile reliable evidence in good faith, and no one data source is conclusive merely because manifest error is not proved.

4.3. The calculation excludes Excluded Events, all minutes outside Business Hours and interruptions shorter than five consecutive Business-Hours minutes, but includes material degradation during Business Hours where the contracted core function is not reasonably usable. Planned suspension time during Business Hours is excluded only where the suspension meets the Terms of Service and is attributable to the Tenant or required by law or urgent security. A Henry convenience suspension or Henry-caused dependency failure during Business Hours is not automatically excluded.

4.4. The commitment is backed by the Service Credits and repeated-failure right in Section 8 but is not a warranty of uninterrupted or error-free operation.

5. Events Outside Availability Measurement

5.1. To distinguish Henry-controlled availability from events outside its control or actions required to protect the Service, Downtime excludes unavailability, degradation or delay caused by:

• scheduled maintenance notified at least five days in advance where reasonably practicable, or emergency maintenance required for security, law, provider stability or material risk;
• Tenant Data, systems, devices, browsers, networks, credentials, permissions, configurations, code, integrations, excessive requests, unsupported use, breach or Tenant-requested work;
• an independent Third-Party Service selected, contracted or controlled by the Tenant, or a provider event outside Henry's reasonable control that Henry did not cause and could not reasonably avoid or mitigate through the architecture included in the applicable plan;
• force majeure, load shedding, government action, legal prohibition or a widespread cyberattack not caused by Henry's failure to use reasonable safeguards;
• beta, preview, trial, free, experimental or retired functionality;
• a security control, threat block, rate limit, credential revocation or fail-safe applied in good faith; or
• an issue that cannot reasonably be verified, or a period when the Tenant prevents or materially delays investigation.

5.2. Henry will use reasonable efforts to schedule material planned maintenance outside Business Hours and to minimise its duration. Scheduled maintenance may not exceed eight hours in a calendar month without advance notice of the exceptional circumstances, unless urgent security or law requires otherwise.

6. Incident Management and Support

6.1. Henry prioritises Incidents according to verified customer impact and may reclassify them as facts change. Multiple tickets with one cause may be treated as one Incident.

6.2. Henry's automated security and operational monitoring may operate continuously, but standard availability measurement, human support, triage and incident response operate only during Business Hours through support@henryai.co.za or the in-application support function for designated Tenant contacts. Alerts or reports received outside Business Hours are queued for the next Business-Hours support window. All standard response, update and root-cause targets, and all standard human restoration efforts, run only during Business Hours. The applicable initial-response target begins when, during Business Hours, Henry monitoring or a designated Tenant contact provides enough information to start reasonable triage and is not postponed merely because every diagnostic item is not yet available.

6.3. After Henry provides the initial Response, Henry will use reasonable efforts during Business Hours to restore the affected Service or provide a reasonable continuity workaround as soon as reasonably possible. The standard SLA does not include or promise a fixed, maximum or target incident-restoration time. Henry may implement a workaround, rollback, temporary restriction or alternative process, and is not required to permanently correct every underlying defect as part of incident restoration. Restoration timing may depend on technical complexity, provider action, available information and Tenant cooperation or decisions. This Section 6.3 does not replace the separately stated RTO that applies after Henry declares a recoverable disaster under Section 8.4.

6.4. Henry will acknowledge and communicate a material P1 within the applicable initial-response target during Business Hours, provide an update at least every eight Business Hours after the initial Response until restoration or a reasonable workaround, and provide a final restoration notice. For P2, Henry will provide an update at least once each Business Day after the initial Response while material impact continues. Updates will state known impact, work performed, workaround, next action and next update time. Preliminary information may change. Personal-information Security Compromises and related notices are governed by the Privacy Policy Section 10 and may run in parallel and are not delayed merely because the support clock is paused.

6.5. Henry will conduct a review proportionate to each P1 Incident and provide the affected Tenant a non-confidential root-cause and corrective-action summary within twenty Business Days after restoration, or a progress date where investigation reasonably requires longer. The summary may protect another customer, security-sensitive detail, privilege and a lawful investigation without withholding information reasonably needed to understand the cause, impact and corrective action.

6.6. Standard P1 to P4 human support is included only during Business Hours through support@henryai.co.za or the in-application support function for designated Tenant contacts. Continuous automated monitoring does not constitute continuous human support or expand availability measurement beyond Business Hours. Telephone support, dedicated support personnel, faster response or update targets, any committed incident-restoration time, extended hours, weekend or public-holiday support and on-call assistance are not included in the standard SLA. Abusive use may result in proportionate restrictions under the AUP.

7. Working Together During an Incident

7.1. Prompt cooperation helps Henry investigate and restore the Service efficiently. Account and credential duties are governed by the Terms of Service Section 3. For this SLA, the Tenant must maintain current contacts and independent copies of critical source data, use supported configurations, monitor external dependencies, report Incidents promptly, mitigate impact and cooperate with investigation and testing.

7.2. A Support Ticket should identify the Tenant, reporting User, affected Service, date and time, affected Users, business impact, reproduction steps, expected and actual behaviour, relevant references, errors, logs, screenshots and recent Tenant-side changes. It must not include unnecessary personal information, passwords or secrets.

7.3. Henry is not responsible for delay caused by incomplete information, unavailable Tenant personnel or blocked access.

8. Service Credits and Restoration

8.1. Service Credits recognise a material shortfall against the availability commitment. If Monthly Availability falls below 99.9% because of qualifying Downtime:

8.2. Service Credits apply only to recurring subscription fees for the affected Henry Ingest, Henry Insights or subscription-based Henry Exchange feature. They are the sole monetary remedy for the availability shortfall itself, are capped at 40% of the Affected Monthly Recurring Fee for the month, apply to a future recurring invoice rather than as cash, expire after 12 months, and are unavailable while the Tenant is materially overdue on undisputed amounts or in material breach that caused the Incident. They do not apply to commissions, transaction-based amounts, ad hoc work, implementation, usage, external data, independent third-party charges, professional services or any other non-recurring payment. They do not reduce an unrelated data-protection, confidentiality, IP or other legal claim; their treatment under Henry's aggregate liability cap is governed by the Terms of Service Section 7.

8.3. To qualify, the Tenant must have reported an Incident not already detected by Henry promptly, provided reasonable cooperation, paid all undisputed amounts and submitted a substantially complete written claim within 60 days after the end of the affected month, identifying the Incident and requested calculation. Henry will help correct a non-material deficiency and ordinarily decide the claim within 45 days. The evidence standard in Section 4.2 applies; Henry's calculation is not conclusive where reliable contrary evidence exists.

8.4. Henry maintains standard backup and recovery processes for covered production data under its control in Supabase and Amazon S3. These processes have a target RPO of twenty-four ordinary hours and a target RTO of twenty-four Business Hours after Henry declares a recoverable disaster. The RPO is measured as an elapsed data-loss window. The RTO runs only during Business Hours and pauses outside Business Hours. Henry will prioritise restoration and test a material Supabase and Amazon S3 restoration process at least every six months under the Security and Incident Schedule. These targets exclude Tenant-deleted data, a Tenant-controlled or independent source, granular historic-state restoration, Zoho WorkDrive content and permanent archival.

8.5. If Monthly Availability is below 99.9% in three calendar months in any rolling six-month period, the Tenant may terminate the materially affected covered Service by written notice within 30 days after the third affected month and receive a refund of unused prepaid recurring Fees for the post-termination period. This termination right is not available for an Excluded Event or where the Tenant did not materially cooperate with restoration.

8.6. Where a suspension is not attributable to the Tenant and materially prevents use of a covered component, Henry will apply the availability calculation or a fair pro-rata credit under the Terms of Service. Where a material or business-critical Tenant has a signed continuity Annex, the parties will perform the stated joint restoration, dependency and manual-workaround tests and retain the results for the agreed assurance period.

9. Changes and Contact

9.1. Changes to this SLA and their acceptance are governed by the Terms of Service Section 11. The version applicable to a paid fixed Subscription Period will not be materially reduced during that period except for law or an urgent security requirement; a materially adverse ordinary change applies on renewal after notice.

9.2. Standard support, legal and custom SLA queries, including security incidents, may be sent to legal@henryai.co.za. Contractual notices must be sent under the Terms of Service Section 12.

END OF SERVICE LEVEL AGREEMENT