Service Level Agreement

Effective Date: August 13, 2026
Version: 1.0
Operator: ARYX LLC (aryx.pro). The contracting party named on an Order Form controls for that transaction.

1. Purpose and Scope

This Service Level Agreement ("SLA") describes the availability commitments, maintenance practices, incident-response targets, and Service Credit remedies that ARYX LLC ("ARYX", "we", "us") provides to a customer ("Customer" or "Tenant") for the ARYX hosted software services (the "Services"). This SLA is incorporated by reference into, and forms part of, the Master Subscription Agreement or Terms of Service executed between ARYX and Customer (see /legal/terms / the applicable order form). Capitalized terms not defined here have the meaning given in the governing agreement.

This SLA applies to Customer's production use of the Services under an active, paid subscription in good financial standing. It does not apply to free, trial, evaluation, sandbox, pre-release, or beta offerings, which are provided "as is" without any availability commitment (see Section 7.7).

This SLA governs availability and support only. It does not modify ARYX's obligations concerning data protection, security, or the handling of Protected Health Information ("PHI"), which are addressed in the Data Processing Addendum and Business Associate Agreement (see /legal/dpa and /legal/baa), nor does it modify the financial-state, refund, and settlement provisions described in ARYX's refund and settlement standards (see also /legal/billing).

2. Defined Terms

• Services — The multi-tenant ARYX applications made available to Customer under subscription, including EnrollFlow (member enrollment), ARYX CRM (relationship management for Tenant staff), ARYX Accounts (identity, single sign-on, org/tenant provisioning, and the subscription/billing engine at aryx.pro / app.aryx.pro), and, where subscribed, AdvisorIQ and the IT Ticketing/Support application.
• Covered Services — The specific production Services and environments listed in Section 3 to which the Uptime commitment applies.
• Authorized User — A Member, enrollee, or Tenant staff user permitted by Customer to access the Services under Customer's tenant.
• Member Data — PHI, member PII, and financial/transaction data processed by ARYX on Customer's behalf, isolated per Tenant via Postgres Row-Level Security ("RLS").
• Processor — Authorize.Net, the third-party payment processor. The Tenant holds and controls the Authorize.Net merchant account; ARYX is not the merchant of record (see Section 8).
• Subprocessor — A third party engaged by ARYX to support delivery of the Services, including Supabase (database, auth, storage), Vercel (application hosting), Resend (email), and GoTo (SMS/voice).
• Availability — The percentage of time in a calendar month during which the Covered Services are materially usable by Authorized Users, as measured under Section 4, excluding all events in Section 7.
• Downtime — A period during which the Covered Services are unavailable as defined in Section 4, excluding all events in Sections 7 and 8.
• Monthly Uptime Percentage — The metric calculated under Section 4.2 for a given calendar month.
• Service Credit — The sole and exclusive remedy for a failure to meet the Uptime commitment, calculated under Section 9.
• Scheduled Maintenance — Planned maintenance for which ARYX provides advance notice under Section 6.
• Emergency Maintenance — Unplanned maintenance required to preserve security, integrity, or availability, described in Section 6.3.

3. Covered Services and Environments

The Uptime commitment in Section 5 applies only to the production environments of the Services to which Customer holds an active subscription, accessed over the public internet at the Customer's provisioned tenant hostnames (for example, app.aryx.pro, {slug}.crm.aryx.pro, and the Customer's EnrollFlow enrollment surface).

The following are not Covered Services and carry no Uptime commitment: non-production environments (development, staging, sandbox, preview, or test); the ARYX marketing website and documentation; beta, early-access, or feature-flagged functionality (see Section 7.7); functionality supplied by a Subprocessor or Processor to the extent of that party's own service (see Sections 7.6 and 8); and any integration or endpoint operated or controlled by Customer or a Customer-selected third party.

4. Definition and Measurement of Availability

4.1 What Constitutes Downtime

A Covered Service is considered "down" during any period in which authenticated Authorized Users are unable to load the core application or complete core transactions due to a fault within ARYX's control, and the failure is not attributable to any event in Sections 7 or 8. Core transactions include user authentication and single sign-on via ARYX Accounts, EnrollFlow enrollment submission, ARYX CRM record access, and RLS-scoped read/write to Member Data.

Isolated errors, degraded performance that does not prevent core transactions, individual feature faults that do not render the application unusable, and errors affecting a single Authorized User or session do not constitute Downtime.

4.2 Measurement Method

Availability is measured per calendar month, in one-minute sampling intervals, using ARYX's monitoring of the Covered Services' production endpoints. The Monthly Uptime Percentage is calculated as:

Monthly Uptime % = ((Total Minutes in Month − Excluded Minutes − Downtime Minutes)
                     ÷ (Total Minutes in Month − Excluded Minutes)) × 100

Where Excluded Minutes are minutes attributable to any event in Sections 6 (maintenance), 7 (exclusions), or 8 (non-Downtime events), and Downtime Minutes are contiguous minutes of Downtime as defined in Section 4.1, measured from the earlier of ARYX's detection or Customer's conforming report (Section 9.3) until restoration.

ARYX's monitoring records and system logs are the authoritative source for availability determinations. Where Customer disputes a measurement, Customer may submit supporting evidence within the claim window in Section 9.3, and ARYX will review in good faith.

5. Uptime Commitment

ARYX will use commercially reasonable efforts to make the Covered Services available at a Monthly Uptime Percentage of at least 99.9% during each calendar month of the subscription term (the "Uptime Commitment").

The Uptime Commitment excludes all events described in Sections 6, 7, and 8. The Uptime Commitment is a target measured over a full calendar month; it does not apply to any partial month, nor to any period during which Customer's subscription is suspended, expired, or delinquent.

6. Maintenance

6.1 Scheduled Maintenance

ARYX may perform Scheduled Maintenance to deploy updates, patch dependencies, and maintain the Supabase (database/auth/storage) and Vercel (hosting) infrastructure underlying the Services. ARYX will use commercially reasonable efforts to conduct Scheduled Maintenance during a low-traffic maintenance window 00:00–04:00 U.S. Eastern on weekends.

6.2 Notice Periods

ARYX will provide advance notice of Scheduled Maintenance expected to cause material unavailability, targeting at least five (5) business days notice via email and/or the ARYX Accounts in-app notification surface. Time attributable to properly noticed Scheduled Maintenance is treated as Excluded Minutes and does not count as Downtime.

6.3 Emergency Maintenance

ARYX may perform Emergency Maintenance without advance notice where necessary to address a security vulnerability, active threat, data-integrity risk, Subprocessor incident, or imminent availability risk. ARYX will use commercially reasonable efforts to notify affected Customers as soon as practicable, which may occur during or after the maintenance. Time attributable to Emergency Maintenance is treated as Excluded Minutes and does not count as Downtime.

7. Exclusions

The Uptime Commitment and Service Credits do not apply to, and Availability calculations exclude, any unavailability, suspension, or degradation caused in whole or in part by:

1. Scheduled Maintenance noticed under Section 6, and Emergency Maintenance under Section 6.3.
2. Force majeure — events beyond ARYX's reasonable control, including natural disasters, war, terrorism, civil unrest, labor actions, governmental action, pandemic, widespread internet or utility failures, and denial-of-service or other malicious attacks not resulting from ARYX's failure to maintain commercially reasonable safeguards.
3. Third-party / Subprocessor outages — failures, degradation, throttling, or maintenance of any Subprocessor or upstream provider, including Supabase, Vercel, Resend, and GoTo, and any public internet, DNS, CDN, or network-transit fault outside ARYX's infrastructure.
4. Processor outages — any failure, latency, maintenance, or degradation of Authorize.Net, its Customer Information Manager ("CIM"), Accept.js tokenization, webhook delivery, or settlement/posting systems (further addressed in Section 8).
5. Customer-caused conditions — Customer's or an Authorized User's acts or omissions, including misconfiguration, misuse, exceeding documented rate or volume limits, use of the Services in a manner not permitted by the governing agreement or documentation, Customer-side integrations or code, Customer network or device faults, invalid credentials, or failure to apply a required update.
6. Suspension of the Services undertaken in accordance with the governing agreement or ARYX's Acceptable Use Policy (for example, for non-payment, security risk, or unlawful use).
7. Beta and pre-release features — any functionality identified as alpha, beta, preview, early-access, experimental, or feature-flagged, which is provided without any availability commitment.
8. Any period for which a Service Credit is otherwise excluded under Section 9, and any unavailability of a Service that is not a Covered Service under Section 3.

8. What Does Not Constitute ARYX Downtime (Payments and Financial State)

Because ARYX orchestrates payment workflow but is not a bank, card network, payment processor, money transmitter, or merchant of record, the following are expressly not Downtime, are excluded from Availability, and do not give rise to a Service Credit. This Section controls in the event of any conflict with Sections 4 or 5, and is read together with ARYX's refund and settlement standards (see also /legal/billing).

1. Processor settlement and posting delays. The timing by which a charge moves through Scheduled → Submitted → Authorized → Captured → Settled, or by which a refund moves through Refund Requested → Refund Authorized → Submitted to Processor → Processor Accepted → Network Processing → Issuer Processing → Posted/Settled, is controlled by the Processor, the card networks, and the issuing/acquiring financial institutions. Such timing is outside ARYX's control and is not a measure of Service availability.
2. Card-network and issuer timing. Authorization holds, batch cut-off times, network processing windows, and issuer-side posting delays are not ARYX Downtime.
3. Processor and payment third-party API failures. Unavailability of Authorize.Net, CIM stored payment profiles, Accept.js tokenization, or inbound Authorize.Net webhook delivery (verified via Processor-specified signature verification) is a third-party condition excluded under Section 7.4, even where it prevents a charge from being submitted or a webhook from being received.
4. Recurring charge engine timing. ARYX operates a schedule-driven recurring charge engine (cron) rather than gateway-native ARB; a scheduled charge that is queued but not yet submitted, or that awaits Processor response, is not Downtime. ARYX will never represent a charge or refund as "Completed" or "Settled" merely because an API returned HTTP 200.

ARYX remains responsible for the availability of the ARYX software that initiates and records these workflows (for example, the EnrollFlow payment-initiation surface and the ARYX Accounts billing engine); a fault in that ARYX-controlled software, not attributable to Section 7, may constitute Downtime.

9. Incident Severity, Response Targets, and Service Credits

9.1 Incident Severity Levels and Response/Restore Targets

ARYX classifies incidents by severity and pursues the following targets. Response times are measured from ARYX's acknowledgement of a conforming report or ARYX's own detection. Response and restore times are targets, not guarantees, and are commercially reasonable efforts.

"Business hours" means 9:00 a.m.–6:00 p.m. U.S. Eastern, Monday–Friday, excluding ARYX holidays. Support is requested through hello@aryx.pro or the IT Ticketing/Support application. Severity is assigned by ARYX in good faith and may be reassessed as facts develop.

9.2 Service Credits Schedule

Where the Monthly Uptime Percentage for a Covered Service falls below the Uptime Commitment in a calendar month, Customer is eligible for a Service Credit calculated as a percentage of the monthly subscription fees paid by Customer for the affected Covered Service for that month:

9.3 Claim Process

To receive a Service Credit, Customer must submit a claim to hello@aryx.pro within thirty (30) days after the end of the calendar month in which the qualifying Downtime occurred. The claim must include: (a) the affected Covered Service and Tenant; (b) the dates, times, and duration of each Downtime period; and (c) any Customer-side logs or evidence reasonably supporting the claim. ARYX will evaluate the claim in good faith against its monitoring records (Section 4.2) and, if approved, apply the Service Credit.

9.4 Credit Cap, Form, and Sole Remedy

Service Credits are issued as a credit against a future invoice for the affected Covered Service and have no cash value; they are not refunds or payouts and are not payable on termination unless required by law. In no event will the total Service Credits issued to Customer for any single calendar month exceed 100% of the monthly subscription fee paid for the affected Covered Service for that month. Service Credits are the sole and exclusive remedy for any failure by ARYX to meet the Uptime Commitment or any other service-level target in this SLA. This SLA does not expand ARYX's aggregate liability, which remains subject to the limitation-of-liability provisions of the governing agreement.

9.5 Eligibility Conditions

Customer is not eligible for a Service Credit for any month in which Customer's account is past due or in material breach, and Service Credits do not apply to any period excluded under Sections 6, 7, or 8, or to any Service that is not a Covered Service under Section 3.

10. Customer Responsibilities

Customer will: (a) maintain valid administrative and Authorized User configurations, including correct tenant provisioning through ARYX Accounts; (b) use current, supported browsers and integration methods; (c) safeguard credentials and promptly report suspected compromise to legal@aryx.pro; (d) maintain its own Authorize.Net merchant account and Processor configuration; (e) report incidents promptly with sufficient detail for reproduction; and (f) not exceed documented rate, volume, or usage limits. Failure to meet these responsibilities may exclude affected periods from Availability under Section 7.5.

11. Changes to this SLA

ARYX may update this SLA from time to time in accordance with the change-control terms of the governing agreement. Material changes that reduce the Uptime Commitment or the Service Credit schedule will be communicated to Customer with reasonable advance notice via email and/or the ARYX Accounts notification surface. The version and Effective Date in the metadata block above govern the then-current SLA.

3. Precedence and Cross-References

In the event of a conflict, the order form and governing agreement control over this SLA except as to the specific availability and Service Credit terms stated here. This SLA is read together with, and does not modify, the following: /legal/terms (governing agreement and limitation of liability); ARYX's refund and settlement standards (see also /legal/billing) (financial state, refunds, settlement); /legal/dpa (data protection and Subprocessors); and /legal/baa (PHI and HIPAA obligations).

---