Service Level Agreement

Effective Date: September 28, 2026

This Service Level Agreement (“SLA”) forms part of the Agreement between Five Jars Corp (“Five Jars,” “we,” or “us”) and Customer under the Deyra Terms & Conditions or an applicable master agreement. Capitalized terms not defined here have the meanings in that agreement.

1. Scope and Covered Services

A Covered Service is a production Deyra Subscription Service expressly covered by this SLA, an applicable Order Form, or the service documentation incorporated into that Order Form. Unless an Order Form expressly provides different coverage, this SLA covers the Deyra-hosted, generally available production functionality of paid Subscription Services, including the user interfaces, APIs, query endpoints, and processing or integration infrastructure necessary to operate the purchased Service (the Core Platform). Coverage is not limited to AI Assistant, AI Agent, or any other particular product name.

Coverage is assessed for the affected purchased Service. An incident affecting one Service does not automatically establish Downtime for other Services that remain operational. An Order Form may identify covered components or regions and expressly amend this SLA as provided in the Terms. A later documentation change does not remove agreed coverage during an active Subscription Term.

This SLA does not cover alpha, beta, preview, experimental, or unsupported features; free plans or trials unless expressly included; Customer-operated infrastructure; or independently operated third-party systems, networks, or data sources. Failures involving external dependencies are assessed under Section 6 and are not excluded solely because a provider is a third party.

This SLA addresses availability and the support response targets below. It does not create a separate latency, synchronization-frequency, or processing-speed guarantee unless expressly agreed in an Order Form. Other product obligations are governed by the Terms and applicable Order Form; data-processing and security obligations remain governed by the applicable Agreement and any executed DPA.

2. Definitions

• Monthly Uptime Percentage (MUP): For each affected Covered Service and applicable region, (Total minutes in month − Downtime minutes) ÷ Total minutes in month × 100%. If coverage begins or ends during a month, only the minutes within the coverage period are used in the numerator and denominator.
• Downtime: Periods when the Core Platform necessary to operate a Covered Service is unavailable from the public internet to perform its core function or process valid requests due to a Deyra-controlled incident, measured in continuous five-minute intervals. Partial intervals under five minutes are not counted. A Service’s core function depends on the purchased functionality and is not limited to AI query processing. Exclusions in Section 6 are applied only to the affected period and function.
• Business Hours: Monday–Friday, 09:00–18:00 Eastern Time, excluding U.S. federal holidays, unless otherwise agreed.
• Planned Maintenance: Maintenance scheduled with at least 72 hours’ notice.
• Emergency Maintenance: Urgent maintenance required to address active incidents or security issues, limited to what is reasonably necessary.

3. Service Availability Commitment

We will use commercially reasonable efforts to provide a Monthly Uptime Percentage of at least 99.95% for each Covered Service.

3.1 Measurement

Availability is measured at the Deyra-controlled service ingress using our monitoring systems for the applicable Core Platform interfaces and endpoints. An incident is assessed against the affected Service’s core function; availability of an unrelated endpoint does not establish availability of an impaired Covered Service. Customer-provided timestamps, logs, and incident reports may assist validation. Excluded events are described in Section 6.

3.2 Maintenance Windows

Planned Maintenance is typically scheduled Sundays 02:00–06:00 UTC and will be announced at least 72 hours in advance. We strive to perform maintenance without service interruption and will provide the expected impact and duration when an interruption is anticipated. Emergency Maintenance is limited to a reasonable duration, with notice as soon as practicable. Only the actual affected maintenance period is excluded from Downtime.

4. Incident Response Targets

Five Jars provides support for Covered Services during Business Hours, with 24×7 response for Severity 1 incidents. Submit incidents to the support contact in Section 10 with the affected Service, impact, start time, and relevant diagnostics. Response targets run from receipt of the report; business-hour targets count Business Hours only.

Severity	Example	Initial Response	Status Updates	Target Workaround/Resolution
Sev 1 – Critical	Complete Covered Service outage; core interface or APIs unavailable; core processing unavailable	1 hour (24×7)	Hourly until mitigated	Workaround target: 4 hours; resolution: commercially reasonable efforts
Sev 2 – High	Significant degradation; multiple integrations failing; slow responses; regional impact	4 business hours	Every business day	Workaround/resolution: commercially reasonable efforts
Sev 3 – Medium	Single integration issue; limited feature impairment; non-critical bug or UI issue	1 business day	Weekly	Added to backlog; prioritized by impact
Sev 4 – Low	Cosmetic issue; documentation request; feature question	2 business days	As needed	Handled through standard support

These are response and update commitments and workaround targets, not guaranteed resolution times. Service credits are calculated only from the availability thresholds in Section 5.

5. Service Credits

If MUP falls below the commitment, Customer may request a credit against the subscription fees attributable to the affected Covered Service and region for the affected month.

Monthly Uptime Percentage (MUP)	Credit
< 99.95% and ≥ 99.9%	5%
< 99.9% and ≥ 99.0%	10%
< 99.0% and ≥ 98.0%	25%
< 98.0%	50%

For annual or other non-monthly billing, the monthly fee is the subscription fee for the billing period divided by the number of months in that period. For a bundle, use the allocation in the Order Form; if none is stated, the parties will reasonably determine the portion attributable to the affected Service. This calculation does not change the Order Form’s price or billing schedule.

• Credits apply to future invoices and are not refundable in cash.
• Credits are capped at 50% of the monthly fee for the affected month and Covered Service. Overlapping incidents do not generate duplicate credits for the same Downtime.
• No credits apply to free plans or trials, or periods when account payments are overdue.
• To the maximum extent permitted by law, credits are the sole and exclusive remedy for failure to meet this SLA’s uptime commitment, unless an Order Form expressly provides otherwise. This does not limit remedies for a separate breach of other obligations under the Agreement or DPA.

5.1 Requesting Credits

Submit a request to [email protected] within 30 days after the month in which the commitment was not met. Include:

• Account name and billing email;
• Affected Covered Service, dates, times, and regions;
• Description of the business impact;
• Relevant logs or incident IDs, where available.

We will validate the request using our logs and monitoring data and relevant information supplied by Customer.

6. Exclusions

Downtime excludes unavailability to the extent caused by:

• Events beyond our reasonable control, including force majeure, large-scale internet outages, or DDoS attacks beyond our reasonable control;
• Failures of Customer networks, firewalls, VPNs, authentication systems, or internet providers;
• Unavailability of Customer-selected external data sources, applications, or APIs, or invalid credentials or permissions for those systems;
• External service or CDN failures beyond our reasonable control; use of a Five Jars provider does not by itself exclude an incident in the Core Platform;
• Customer misuse or misconfiguration, or a suspension permitted by the Agreement as a result of Customer’s or its users’ violation;
• Rate limiting or resource exhaustion caused by traffic beyond contracted capacity without prior notice or by Customer configuration;
• Beta, preview, or other non-covered functionality;
• Planned Maintenance meeting Section 3.2 and Emergency Maintenance limited to a reasonable period.

Inaccurate, incomplete, or outdated source data alone does not establish Downtime. A failure of Deyra-controlled infrastructure to perform a Covered Service’s core function is evaluated under the Downtime definition, even when that function involves a third-party connection. An unrelated violation or excluded event does not exclude an otherwise qualifying Deyra-controlled outage.

7. Customer Responsibilities

Customer must maintain current incident contacts; configure Services according to documentation; maintain required source-system connectivity, credentials, and permissions; use the Services within contracted capacity; notify us of material forecasted traffic increases; and reasonably cooperate with incident diagnosis. Reports should identify the affected function and omit unnecessary personal information or secrets.

8. Relationship to the Agreement

This SLA controls conflicts relating to service-level coverage, availability commitments, measurement, and service credits, subject to any expressly agreed amendment. General “as is” or “as available” wording in the Terms does not negate this SLA. The remainder of the Agreement continues to apply.

9. Changes to this SLA

We may update this SLA with at least 30 days’ notice through the status page, dashboard, or email to Customer’s administrator contacts. Changes that reduce agreed coverage, availability commitments, or credits take effect at renewal unless the parties expressly agree otherwise. Operational changes required for security or legal compliance may take effect sooner where reasonably necessary, but do not by themselves reduce agreed contractual commitments or credits.

10. Contact and Support

• Support: [email protected]
• Status page: status.deyra.ai
• Emergency escalations (Sev 1): Provided after ticket creation if requested