Umowa o Poziomie Usług
Nasze zobowiązania dotyczące dostępności, jak je mierzymy i co się dzieje, gdy nie są dotrzymywane.
Data wejścia w życie: 13 czerwca 2026. Ostatnia aktualizacja: 22 sierpnia 2026. Dotyczy wszystkich płatnych planów.
Zobowiązania dotyczące dostępności
Dążymy do 99,9% miesięcznej dostępności wszystkich objętych usług. Odpowiada to nie więcej niż około 43 minutom przestoju w miesiącu kalendarzowym, czyli około 8,8 godzinom w skali całego roku.
Witryna ZillaSoft
zillasoft.io i wszystkie strony statyczne
Obsługiwane przez AWS CloudFront + S3
API synchronizacji w chmurze
Punkty końcowe uwierzytelniania, synchronizacji i subskrypcji
Obsługiwany przez Railway (serwer API) i Neon (baza danych)
Aplikacje desktopowe i rozszerzenie przeglądarki
Główne funkcje działają lokalnie na Twoim urządzeniu lub w Twojej przeglądarce
Kluczowe funkcje zwiększające produktywność pozostają dostępne lokalnie nawet podczas przerw w działaniu usług w chmurze.
Jak mierzymy dostępność
Dostępność jest obliczana miesięcznie jako procent minut w miesiącu kalendarzowym, podczas których każda usługa jest dostępna i odpowiada na żądania. Dostępność jest określana przez zautomatyzowane kontrole kondycji uruchamiane w regularnych odstępach czasu z wielu regionów geograficznych.
Usługa jest uważana za „niedostępną", gdy przez dwie lub więcej kolejnych minut nie odpowiada na kontrole kondycji. Krótkie przejściowe błędy, które rozwiązują się w obrębie jednego interwału kontrolnego, nie są wliczane do czasu przestoju.
Bieżący stan usługi i historia incydentów są zawsze dostępne na stronie statusu.
Co nie jest objęte
Zaplanowana konserwacja zakomunikowana z co najmniej 48-godzinnym wyprzedzeniem
Przerwy spowodowane przez zewnętrznych dostawców (Auth0, AWS, Stripe, Railway, Neon oraz inne usługi wykorzystywane do prawidłowego działania aplikacji ZillaSoft) poza kontrolą ZillaSoft
Aplikacje dystrybuowane za pośrednictwem marketplace'ów podmiotów trzecich (obecnie marketplace'y Atlassian, Zendesk i Freshworks oraz każdy marketplace, który możemy dodać w przyszłości), które działają na infrastrukturze obsługiwanej przez te platformy
Dystrybucja i dostępność aktualizacji rozszerzenia przeglądarki za pośrednictwem sklepów podmiotów trzecich (Chrome Web Store, Microsoft Edge Add-ons, Firefox Add-ons)
Zdarzenia siły wyższej (klęski żywiołowe, wojna, pandemia)
Problemy spowodowane niewłaściwym korzystaniem przez klienta lub próbami nieautoryzowanego dostępu
Funkcje w fazie beta lub przed wprowadzeniem, wyraźnie oznaczone jako takie
Aplikacje, które ZillaSoft dystrybuuje za pośrednictwem marketplace'ów podmiotów trzecich (aplikacje Snipzilla Templates dla Jira, Zendesk i Freshdesk oraz każda aplikacja z marketplace'u, którą wydamy w przyszłości), działają w całości na infrastrukturze obsługiwanej przez te platformy. ZillaSoft nie hostuje, nie monitoruje ani nie kontroluje tej infrastruktury. Dostępność tych aplikacji podlega zatem zobowiązaniom serwisowym platformy goszczącej, a nie niniejszej umowie SLA, i za ich przestoje nie są przyznawane żadne kredyty usługowe na podstawie niniejszej umowy SLA. Zobowiązanie do 99,9% podane na tej stronie dotyczy usług obsługiwanych przez ZillaSoft: witryny ZillaSoft oraz interfejsów API w chmurze naszych aplikacji komputerowych i naszego rozszerzenia przeglądarki.
Planowane prace serwisowe są zazwyczaj przeprowadzane w okresach niskiego ruchu, około godziny 23:00 czasu Gwatemalskiego (05:00 UTC).
Kredyty SLA
Jeśli miesięczna dostępność spadnie poniżej 99,9%, dotknięci klienci z płatnymi planami mogą ubiegać się o kredyt usługowy. Kredyty są obliczane jako procent miesięcznej opłaty subskrypcyjnej za daną usługę:
| Miesięczna dostępność | Kredyt |
|---|---|
| 99,0% do poniżej 99,9% | 10% |
| 95,0% do poniżej 99,0% | 25% |
| Poniżej 95,0% | 50% |
Kredyty są stosowane w następnym cyklu rozliczeniowym. Aby ubiegać się o kredyt, otwórz zgłoszenie rozliczeniowe lub napisz na billing@zillasoft.io w ciągu 30 dni od zakończenia miesiąca, którego dotyczy incydent. Kredyty są jedynym środkiem zaradczym w przypadku naruszenia SLA i nie podlegają wymianie na gotówkę.
Klienci enterprise mają warunki SLA określone w swoich indywidualnych umowach o świadczenie usług, które mają pierwszeństwo przed tą stroną.
Reagowanie na incydenty
Wykrywanie
Zautomatyzowane kontrole kondycji powiadamiają nas w ciągu minut o każdej przerwie w świadczeniu usług.
Komunikacja
Strona statusu jest aktualizowana w ciągu 1 godziny od potwierdzenia incydentu. Aktualizacje e-mail są wysyłane do dotkniętych użytkowników w przypadku przerw trwających ponad 30 minut.
Rozwiązanie
Raport po incydencie jest publikowany na stronie statusu w ciągu 48 godzin od rozwiązania.
| Poziom ważności | Przykład | Cel reakcji |
|---|---|---|
| Krytyczny | Całkowita awaria | 4 godziny |
| Wysoki | Główna funkcja niedostępna | 1 dzień roboczy |
| Średni | Częściowy problem | 3 dni robocze |
| Niski | Kosmetyczny / niekrytyczny | 5 dni roboczych |
Cele reakcji oznaczają wstępne potwierdzenie, a nie czas rozwiązania. Cele obowiązują w normalnych godzinach pracy.
Pytania dotyczące planu?
Jeśli masz specyficzne wymagania SLA dla wdrożenia enterprise, skontaktuj się z nami, a omówimy szczegóły.
Skontaktuj się z nami