Service Level Agreement

This Service Level Agreement (the "SLA") sets out the availability commitments AhuraSense makes for the eligible services listed below, how availability is measured, and the service credits available if we do not meet a commitment in a given calendar month.

The contracting entity is AhuraSense Technologies Private Limited (2/26 Umiya Nagar, Nirnay Nagar, Ahmedabad, Gujarat 382481, India) unless an Order Form, Master Services Agreement, invoice, or other written agreement expressly identifies another AhuraSense entity — such as AhuraSense Ltd (20 Wenlock Road, London, England N1 7GU, United Kingdom) — as the contracting party. References to "AhuraSense", "we", "us", or "our" mean the applicable contracting entity.

This SLA forms part of, and is governed by, the AhuraSense Terms & Services. Capitalised terms not defined here have the meaning given in the Terms. Where an order form, enterprise agreement, or negotiated addendum states different commitments, that document prevails for the services it covers.

Commitments are stated per service, per region, and per calendar month. We deliberately do not apply a single headline number to every service: a reserved multi-GPU cluster, an object storage endpoint, and an on-demand single GPU have materially different failure characteristics, and this SLA reflects those differences honestly.

• Monthly Uptime Percentage — the availability figure calculated for an eligible service in a region for a calendar month, using the formula in this SLA.
• Unavailable / Unavailability — a state in which an eligible resource is wholly unreachable or unable to perform its core function through no fault of the customer, as observed by our monitoring systems. Degraded performance that does not render the resource unusable is not Unavailability.
• Downtime Minutes — the number of minutes in the month during which a resource was Unavailable, measured in consecutive-minute intervals.
• Excluded Minutes — minutes attributable to Scheduled Maintenance or to any circumstance listed under SLA Exclusions.
• Service Credit — a credit applied to your AhuraSense Cloud account, expressed as a percentage of the monthly charges for the affected service in the affected region.
• Region — a distinct AhuraSense Cloud geographic deployment in which a Service is made generally available.
• Control Plane — the management APIs, console, and orchestration systems used to create, modify, and inspect resources, as distinct from the running workloads themselves.

This SLA applies only to paid, generally available AhuraSense Services expressly identified as SLA-eligible in the applicable product description, Order Form or this SLA. A Service is covered only after it has been made generally available in the relevant region.

Alpha, beta, preview, technology-preview, evaluation, trial, free-tier, experimental, preemptible, spot and expressly interruptible Services are excluded unless an Order Form expressly states otherwise.

A Service not listed as SLA-eligible does not acquire an availability commitment merely because it interoperates with a covered Service.

For eligible Cloud Compute resources, the applicable Monthly Uptime Commitment is the commitment published for the relevant compute product or stated in the Customer's Order Form. Where no separate higher commitment is expressly stated, eligible standard Cloud Compute carries a 99.9% Monthly Uptime Commitment.

The commitment applies to platform-side availability of the allocated compute resource and does not guarantee uninterrupted operation of Customer applications, guest operating systems, software dependencies or external networks.

A compute resource is Unavailable when a platform-side failure prevents the resource from operating and AhuraSense is unable to restore or replace the affected allocation within the measured Downtime period.

Eligible on-demand GPU resources carry a 99.5% Monthly Uptime Commitment unless another commitment is stated in the applicable product description or Order Form. Reserved or dedicated GPU capacity may carry a higher commitment where specified in the relevant reservation Order Form.

A GPU resource is Unavailable where a platform-side hardware, accelerator, host, power, interconnect or orchestration failure prevents the relevant allocated GPU capacity from performing its core function and the Customer cannot reasonably access replacement capacity within the covered allocation.

GPU application errors, CUDA or framework errors arising from Customer software, out-of-memory conditions caused by the Customer workload, Customer-selected driver incompatibilities and failure to checkpoint application state are not platform Unavailability.

Preemptible and interruptible GPU capacity does not carry an availability commitment unless expressly stated otherwise.

For the AhuraSense regional network fabric — including intra-region routing, virtual networks, and regional load balancing — we commit to a Monthly Uptime Percentage of 99.99%. The fabric is Unavailable when a customer resource cannot send or receive traffic through our network due to a fault within our infrastructure.

This commitment ends at our network edge. The public internet, upstream transit and peering providers, customer ISPs, customer-managed VPN endpoints, and third-party interconnect partners are outside our control and are excluded. Packet loss, latency, or reachability problems occurring beyond our edge do not constitute Unavailability under this SLA, even where they affect your users.

Unless separately agreed in an order form, this SLA covers availability only and does not set latency, jitter, throughput, or packet-loss targets.

For object storage, we commit to a Monthly Uptime Percentage of 99.99%, measured as the proportion of valid requests to the storage endpoint that are not answered with an internal server error or service-unavailable response.

For block volumes attached to a running instance, we commit to a Monthly Uptime Percentage of 99.9%. A volume is Unavailable when read and write operations to it fail for reasons within our infrastructure.

AhuraSense storage services are designed to provide high durability through redundancy, integrity controls and appropriate failure-domain protection for the relevant storage architecture.

Durability is distinct from availability and does not protect against Customer deletion, overwriting, compromised credentials, ransomware or application-level corruption. Customers remain responsible for backups, versioning and recovery arrangements appropriate to the importance of their data.

Unless expressly stated in an Order Form, durability figures are engineering objectives and do not create separate service-credit entitlements.

For single-node managed databases and the single-node managed Kubernetes control plane, we commit to a Monthly Uptime Percentage of 99.9%.

For high-availability configurations — managed databases deployed with a standby or replica set, and multi-node highly available Kubernetes control planes — we commit to a Monthly Uptime Percentage of 99.95%. The higher commitment reflects that failover to a healthy node can absorb an individual node failure without customer-facing Unavailability.

Brief failover events within a documented failover window, and connection interruptions caused by customer-initiated version upgrades, parameter changes, or resizing operations, are not counted as Downtime. Kubernetes worker nodes are covered under the relevant Cloud Compute or GPU Compute commitment rather than under Managed Services.

For the AhuraSense management console and public management API, the applicable commitment is 99.9% Monthly Uptime where the Service is designated as generally available.

Control Plane Unavailability does not constitute data-plane Unavailability where existing Customer workloads continue operating normally.

Where the Control Plane is not separately charged, an approved Control Plane SLA credit will be calculated against 10% of the Customer's eligible monthly regional service charges for the affected region, unless an Order Form specifies another calculation basis.

Monthly Uptime Percentage is calculated per eligible service, per region, per calendar month, using the following formula:

Monthly Uptime Percentage = ((Total Minutes in Month − Excluded Minutes − Downtime Minutes) / (Total Minutes in Month − Excluded Minutes)) × 100

• Total Minutes in Month is the number of minutes in the calendar month, measured in UTC.
• Excluded Minutes are minutes attributable to Scheduled Maintenance or to any SLA Exclusion. Excluded Minutes are removed from both the numerator and the denominator, so excluded time neither helps nor harms the resulting percentage.
• Downtime Minutes are the sum of consecutive-minute intervals during which the resource was Unavailable. Downtime is measured per resource — per instance, per volume, per cluster, per endpoint — and not averaged across your whole fleet.

A partial minute of Unavailability is counted as a full Downtime Minute. Where a resource is Unavailable for a period shorter than one consecutive minute, that period is not counted as Downtime. For services measured by request success rate — object storage and the Control Plane and API — a minute is treated as a Downtime Minute when the error rate for valid requests in that minute exceeds the applicable threshold.

Measurement is taken from AhuraSense monitoring and telemetry systems, which are the primary record. We will, however, review credible customer-supplied evidence — logs, timestamped traces, probe results, and error responses — and where that evidence demonstrates Unavailability our systems did not record, we will take it into account in good faith when assessing a claim.

Scheduled Maintenance is planned maintenance reasonably required to update, repair, secure or operate the Services.

Where Scheduled Maintenance is expected to create material Customer-facing disruption, AhuraSense will use reasonable efforts to provide advance notice through the status page, Account notification or registered technical contacts. Where practicable, AhuraSense aims to provide at least seventy-two hours' notice of materially disruptive planned maintenance. Shorter notice may be given where operational circumstances reasonably require.

Routine work that does not create Customer-facing Unavailability does not require individual Customer notice. Scheduled Maintenance is excluded from the availability calculation.

Emergency Maintenance is unplanned work we must carry out at short notice to preserve the security, integrity, or stability of the platform — for example applying a critical security patch, mitigating an active exploit, replacing hardware showing imminent failure, or responding to an upstream vendor advisory.

We will give as much notice as circumstances reasonably allow, which in a genuine emergency may be little or none, and we will publish the reason and the resolution on the status page afterwards.

Emergency Maintenance is treated as Excluded Minutes where it is undertaken to prevent imminent harm to the platform, to customer data, or to security. Where an incident is instead the consequence of a failure within our infrastructure, the resulting outage is counted as Downtime and credits apply in the normal way. We will not reclassify an outage as Emergency Maintenance in order to avoid a credit obligation.

The following are excluded from Downtime Minutes and do not qualify for service credits:

• Customer misconfiguration, including incorrect security group, firewall, routing, DNS, IAM, or load balancer settings.
• Exceeding account quotas, service limits, documented rate limits, or provisioned capacity, including resource exhaustion caused by customer workload growth.
• Any alpha, beta, preview, technology preview, trial, evaluation, or free-tier service, and any service not yet generally available in the region concerned.
• Suspension, throttling, or termination of service arising from breach of the Acceptable Use Policy, breach of the Terms of Service, non-payment, or an outstanding balance.
• Force majeure and other events beyond our reasonable control, as described in this SLA.
• Faults in customer software, application code, container images, dependencies, or deployment automation.
• Faults in the customer-managed guest layer — guest operating system, kernel, drivers, agents, patching, filesystem corruption, and in-guest resource exhaustion.
• The public internet, upstream transit and peering providers, customer ISPs, third-party networks, third-party SaaS or API dependencies, and marketplace or third-party software.
• Side effects of DDoS detection and mitigation, including traffic scrubbing, rate limiting, connection throttling, or blackholing applied to protect the platform or other customers.
• Scheduled Maintenance and qualifying Emergency Maintenance.
• Preemptible, spot, or interruptible capacity reclaimed in accordance with its documented terms.
• Unavailability caused by the customer's own actions or those of its users, agents, or contractors — including shutting down, deleting, resizing, or detaching resources, or credential loss and compromise.
• Resources that are stopped, deallocated, suspended, or otherwise not in a running state at the customer's direction.
• Degraded performance that does not amount to Unavailability, and failures to meet latency, throughput, or benchmark expectations not expressly committed in writing.

You are eligible for a Service Credit where, in a calendar month, the Monthly Uptime Percentage for an eligible service in a region falls below the commitment stated for that service, and you submit a valid claim in accordance with the Claim Process below.

• Your account must be in good standing, with no overdue balance at the time the claim is submitted or the credit is applied.
• The affected service must have been a paid, generally available service in that region for the month in question.
• Credits are assessed independently for each service and each region. Falling short in one region does not create a claim against another.
• Where a single incident causes shortfalls in more than one eligible service, credits are calculated separately for each affected service against its own charges.

Service Credits are expressed as a percentage of the monthly charges for the affected Service in the affected region. Tiers are assessed against the applicable Monthly Uptime Commitment for that Service, rather than against a single fixed figure:

• Below the applicable Monthly Uptime Commitment but at or above 99.0% — 10% credit.
• Below 99.0% but at or above 95.0% — 25% credit.
• Below 95.0% — 50% credit.

The same three-tier structure applies to every eligible Service, anchored to that Service's own Monthly Uptime Commitment. Where the applicable commitment is at or below 99.0%, the first tier applies to any shortfall below the commitment down to the 99.0% threshold.

Credits apply only to the monthly charges for the affected service in the affected region for the month in which the shortfall occurred. They are not calculated against your total account spend, against unaffected services, or against charges in other regions. Charges already discounted, credited, or waived are excluded from the calculation base.

The total Service Credits for an eligible Service in a region for any calendar month will not exceed 50% of the eligible monthly charges for that affected Service in that region, unless an Order Form expressly provides a higher remedy.

Credits are applied against future invoices, have no cash value and cannot be transferred.

Service Credits are the sole contractual remedy for failure to meet an availability commitment, except to the extent such limitation is prohibited by Applicable Law or a separately negotiated agreement expressly provides another remedy.

Service Credits are not applied automatically. To claim, you must submit a request within thirty (30) days of the end of the incident giving rise to the claim. Claims received after that period are not eligible.

Submit claims by raising a support ticket from the AhuraSense Cloud console, or by email to [email protected] with the subject line "SLA Credit Request". Each claim must include:

• Your account identifier and the affected region.
• The resource identifiers affected — instance IDs, volume IDs, cluster IDs, endpoint names, or bucket names.
• The start and end timestamps of each period of claimed Unavailability, expressed in UTC.
• Evidence of the failure — error logs, error codes and response bodies, timestamped traces, monitoring or probe output, or screenshots showing the failure and its time.
• A description of the customer-facing impact.

We will acknowledge a claim within two (2) business days and issue a determination within thirty (30) days of receiving a complete claim, requesting further information where needed. If a claim is declined, we will explain the basis for that decision, including the relevant measurement data or exclusion relied upon.

The commitments in this SLA describe our infrastructure. The resilience your application actually experiences depends on how you architect on top of it, and that part remains yours.

• Use redundant deployments and high-availability configurations where continuity matters to you. A single instance will not deliver redundant resilience regardless of our commitments.
• Maintain your own backups, snapshots, versioning, and tested restore procedures. Durability engineering is not a substitute for backups.
• Keep guest operating systems, kernels, drivers, agents, and application dependencies patched and supported.
• Implement retries with exponential backoff, timeouts, circuit breakers, and graceful degradation, particularly for API and storage calls.
• Monitor your own workloads, and keep the technical contacts on your account current so maintenance and incident notices reach you.
• Stay within quotas and published limits, and request increases in advance of planned growth.
• Safeguard credentials, API keys, and access tokens, and follow least-privilege access practice.

Neither party is responsible for failure caused by an event outside its reasonable control that could not reasonably have been avoided or overcome through commercially reasonable measures. Such events may include natural disasters, war, terrorism, civil unrest, widespread utility failure, governmental action, major telecommunications disruption or other extraordinary events of comparable nature.

Ordinary hardware failure, ordinary data-centre equipment failure, routine supplier failure, capacity-management failures, software defects within AhuraSense-controlled systems and incidents that AhuraSense could reasonably have prevented or mitigated through ordinary redundancy and operating controls are not automatically Force Majeure merely because a third-party supplier or facility was involved.

We may update this SLA to reflect changes to our services, infrastructure, measurement methods, or legal and regulatory requirements. The current version is always published on this page with its effective date and last updated date.

Where a change materially reduces a commitment or narrows your rights, we will give at least thirty (30) days notice before it takes effect, by notice to the registered account contacts and on this page. Changes that improve a commitment, add an eligible service, or clarify existing wording may take effect immediately.

Claims are assessed against the version of this SLA in force at the time of the incident. Customers under an enterprise agreement or negotiated addendum are governed by the commitments in that document for its term.

For service credit claims, incident reports, and questions about measurement, contact [email protected] or raise a ticket from the AhuraSense Cloud console.

For contractual questions about this SLA, enterprise commitments, or negotiated addenda, contact [email protected].

Live platform status, incident history, and maintenance notices are published on the AhuraSense Cloud status page.