SLA

The availability commitment NAVORETA UAB gives for Knacto (https://knacto.com), and the service credits that apply where we fall short. This SLA is 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 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 the free-tier allowance, features labelled beta, experimental or preview, the quality or accuracy of what a Crew produces, external services you connect through webhooks or integrations, or availability of your own accounts on those 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 “Available” when a typical Run submitted 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 give rise 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 upstream AI model providers or built-in tool providers, where our reasonable failover has been exhausted and the situation is broadly recognised as an incident of the provider (not of Knacto);

• 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 balance, or breaches of the AUP;

• external services you have connected yourself (webhook targets, databases, third-party APIs);

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

• features labelled beta, experimental, preview or offered 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 drops 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 credit for any single month is capped at the tokens actually spent 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 above are your sole and exclusive remedy for any failure by us to meet the availability commitment. This does not affect the mandatory statutory rights of consumers 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, seven days a week;

• High — scheduled dispatch or webhook triggers are broken, a specific endpoint is failing, or a purchase cannot be completed: 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 a ticket and begin work — they are not a guarantee that every issue will be fully resolved in the same window. Support is provided in English.

8. Incident communication

Where we run 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 publish a short post-incident summary covering what happened, the impact and the follow-up work.