SLA

This SLA sets out the availability commitment FINDEREKA UAB gives for the Cortexly Service at https://cortexly.cloud, and the service credits you may claim where we fall short. It forms part of the Terms of Service.

1. What this SLA covers

The SLA applies to the generally-available paid functionality of the Service — signing in, viewing your token balance and the run ledger, designing crews, dispatching runs (on demand, on a schedule or via webhook), and using the REST API to submit runs and retrieve results. It does not cover free-tier usage, features labelled beta, experimental or preview, the quality or accuracy of what a crew produces, or anything reached through your own model-provider keys or connected external services.

2. Availability commitment

We target a Monthly Uptime Percentage of at least 99.5% for the covered Service. It is calculated as (Total Minutes in the calendar month − Downtime Minutes) ÷ Total Minutes in the month. A minute is considered “Available” when a typical dispatch through the dashboard or the API can be accepted, queued and reach its dispatch step within a reasonable time.

3. What is not counted as Downtime

The following events do not count as Downtime and do not entitle you to service credits:

• planned maintenance announced at least 48 hours in advance, capped at 8 hours per calendar month;

• emergency maintenance carried out to close a security vulnerability or contain an imminent risk;

• outages or degradation at model providers whose API keys you have plugged in (Anthropic, OpenAI, Gemini, xAI and the like), or at the external services your crews connect to;

• rate-limit, quota or billing failures on your own accounts at those providers or connected services;

• interruptions caused by other upstream third parties — hosting, DNS, payment providers, the public internet;

• force majeure — natural disasters, war, civil unrest, government action, general internet outages;

• problems attributable to your configuration of a crew, your webhooks, your keys, exhausted quotas or breaches of the AUP;

• denial-of-service attacks and other malicious traffic that we make reasonable efforts to mitigate;

• features labelled beta, experimental, preview or made available free of charge;

• suspensions applied under the Terms of Service or the AUP.

4. Service credits

Where the Monthly Uptime Percentage in a given month falls below the target, and none of the exclusions above apply, you may claim service credits added to your token balance on the following scale:

• 99.0% up to but not including 99.5% — 5% of the tokens you spent that month;

• 95.0% up to but not including 99.0% — 10% of the tokens you spent that month;

• below 95.0% — 25% of the tokens you spent that month.

Service credits are non-transferable, have no cash value and cannot be exchanged for a money refund. The monthly credit is capped at the tokens you actually spent during that month.

5. Claiming

Send a claim to [email protected] within thirty days of the end of the affected calendar month, providing the account email, the dates and approximate times of the incidents you rely on, and — where you have them — the run identifiers on the ledger that the incidents affected. Accepted claims are credited within fifteen business days of acceptance. Claims filed late or without sufficient detail cannot be processed.

6. Sole remedy

To the maximum extent allowed by law, the service credits described above are your sole and exclusive remedy for any failure by us to meet the availability commitment. This does not affect any mandatory statutory rights that consumers have under EU and Lithuanian law.

7. Support response targets

Alongside uptime, we aim for the following response times, measured in business hours (Monday to Friday, 09:00–18:00 Vilnius time, excluding Lithuanian public holidays), from the moment you write to us or open a dashboard ticket:

• Critical — the platform or API is entirely unavailable, the balance and ledger are inaccessible, or dispatching runs is impossible: within 24 calendar hours, 7 days a week;

• High — scheduled dispatch or webhook triggers are broken, a specific endpoint is failing, or you cannot complete a purchase: within 2 business days;

• Standard — bug reports, ledger questions, billing questions, account queries, general how-to: within 3 business days;

• Feature requests — reviewed on a best-effort basis, with no committed response time.

These targets describe when we acknowledge and begin working on a ticket, not a guarantee that every issue will be fully resolved within the same window. Support is provided in English.

8. Incident communication

Where we operate a public status page, live incidents are posted and updated there. Major incidents are additionally communicated by email to affected account holders and, where relevant, through in-app notices. After material incidents, we aim to publish a short post-incident summary covering what happened, the impact and the follow-up work.