Ten dokument opisuje poziomy dostępności, czasy reakcji, proces eskalacji incydentów i zasady service credits dla platformy DarhimLabs. SLA dotyczy usług produkcyjnych świadczonych w ramach aktywnej subskrypcji i obejmuje główne moduły: dashboard, API, Inbox, bot runtime, webhooki, auth, billing, Knowledge / RAG i narzędzia administracyjne. Nie obejmuje funkcji beta, środowisk testowych, błędów wynikających z konfiguracji klienta ani problemów niezależnych od DarhimLabs, które opisujemy w sekcji 4.
1. Definicje
Uptime oznacza procent czasu w danym miesięcznym okresie rozliczeniowym, w którym podstawowe usługi DarhimLabs są dostępne dla klientów i odpowiadają na żądania w rozsądnym czasie. Uptime jest liczony na podstawie monitoringu syntetycznego, health checks, metryk infrastrukturalnych i potwierdzonych incydentów. Nie każdy wzrost latency jest downtime: jeśli usługa działa, ale wolniej, zdarzenie może zostać zaklasyfikowane jako degraded service.
Downtime oznacza nieplanowaną niedostępność podstawowej usługi produkcyjnej, która uniemożliwia istotnej części klientów korzystanie z funkcji objętej SLA. Downtime nie obejmuje planowanych okien serwisowych, problemów po stronie sieci klienta, błędnej konfiguracji integracji, limitów planu, wyłączonych kluczy API, niedostępności zewnętrznego kanału należącego do klienta ani awarii dostawcy, jeżeli DarhimLabs nie ma realnej kontroli nad zdarzeniem i zapewnia właściwy fallback.
Service Credit to kredyt usługowy przyznawany jako obniżenie opłaty za kolejny okres rozliczeniowy. Nie jest zwrotem gotówki, odszkodowaniem ani karą umowną. Kredyt jest naliczany tylko po prawidłowym wniosku klienta, złożonym w terminie 30 dni od końca okresu, którego dotyczy incydent, i tylko wtedy, gdy DarhimLabs potwierdzi naruszenie SLA.
Incident Severity określa wpływ zdarzenia. P1 oznacza krytyczną niedostępność podstawowej usługi lub wysokie ryzyko dla danych. P2 oznacza istotną degradację funkcji produkcyjnej. P3 oznacza częściową degradację, workaround lub ograniczony wpływ. P4 oznacza niski wpływ, pytanie, kosmetykę lub problem informacyjny. Severity może zostać zmienione po triage, gdy pojawią się nowe dane.
| Pojęcie | Znaczenie | Jak jest mierzone |
|---|---|---|
| Uptime | Dostępność usług produkcyjnych w okresie rozliczeniowym | Monitoring syntetyczny, health checks, status page |
| Downtime | Nieplanowana niedostępność podstawowej funkcji | Potwierdzony incydent i zakres wpływu |
| Maintenance Window | Planowane prace serwisowe | Komunikacja minimum 7 dni wcześniej, max 4h/mies. |
| Service Credit | Kredyt na kolejny okres rozliczeniowy | Procent miesięcznej opłaty, zgodnie z tabelą w sekcji 3 |
2. Tabela SLA per plan
Poziom gwarancji zależy od planu. Starter jest planem wejściowym i działa w modelu best effort. Business otrzymuje gwarancję 99.5% uptime i priorytetowe wsparcie. Enterprise otrzymuje najwyższy poziom dostępności, dedykowanego CSM, on-call dla zdarzeń P1/P2 i możliwość uzgodnienia dodatkowych warunków w zamówieniu lub umowie ramowej.
| Plan | Uptime | Response P1 | Resolution P1 | Wsparcie | CSM |
|---|---|---|---|---|---|
| Starter | Best effort | Best effort | Brak gwarantowanego czasu | E-mail, kolejka standardowa | Nie |
| Business | 99.5% | 4h response dla P1 | 1 dzień roboczy dla P1 | Priority support | Opcjonalnie |
| Enterprise | 99.95% | 1h response dla P1 | 4h resolution dla P1 | On-call 24/7 dla P1/P2 | Tak, dedykowany CSM |
Response time oznacza czas do pierwszej sensownej odpowiedzi zespołu DarhimLabs: potwierdzenia zgłoszenia, klasyfikacji severity i wskazania dalszego kroku. Resolution time oznacza docelowy czas przywrócenia działania lub dostarczenia skutecznego workaroundu dla P1. Czas resolution może zależeć od dostawców zewnętrznych, integracji klienta i konieczności wykonania migracji danych, dlatego dla skomplikowanych incydentów status page zawiera aktualizacje zamiast jednej sztucznej obietnicy.
Starter
Najlepszy dla testów, MVP i małych wdrożeń bez formalnego SLA.
Business
Priorytetowe wsparcie, uptime 99.5% i service credits po spełnieniu warunków.
Enterprise
99.95%, CSM, on-call i szersze pakiety raportowania incydentów.
3. Service Credits
Service Credits są naliczane jako procent miesięcznej opłaty za usługę objętą SLA. Jeżeli klient płaci rocznie, miesięczna opłata jest liczona jako 1/12 opłaty rocznej za właściwy plan i moduły objęte naruszeniem. Kredyt jest stosowany do kolejnego okresu rozliczeniowego i nie jest wypłacany jako gotówka. Łączny limit kredytów w jednym miesiącu wynosi 50% miesięcznej opłaty, nawet jeśli wystąpi kilka incydentów.
Wniosek o kredyt należy złożyć w ciągu 30 dni od końca miesiąca, którego dotyczy incydent, na adres support@darhimlabs.pl lub przez panel Enterprise. Wniosek powinien zawierać nazwę workspace’u, plan, opis wpływu, datę, przybliżony czas zdarzenia, moduły dotknięte problemem i numer incydentu ze status page, jeśli istnieje. DarhimLabs weryfikuje dane z monitoringu i odpowiada w terminie 30 dni roboczych.
| Uptime miesięczny | Kredyt | Przykład | Uwagi |
|---|---|---|---|
| ≥ 99.95% | 0% | 99.96% uptime w miesiącu | SLA spełnione |
| < 99.95% i ≥ 99.5% | 5% | 99.72% uptime w miesiącu | Kredyt dla Enterprise |
| < 99.5% i ≥ 99.0% | 10% | 99.21% uptime w miesiącu | Kredyt dla Business i Enterprise |
| < 99.0% | 25% | 98.7% uptime w miesiącu | Maksymalny próg podstawowy |
| Limit miesięczny | max 50% | Wielokrotne incydenty w jednym okresie | Łączny limit kredytów za okres rozliczeniowy |
Kalkulator kredytu
Przykład naliczenia
Jeśli Enterprise kosztuje 4 000 PLN miesięcznie, a uptime w miesiącu wyniósł 99.42%, kredyt wynosi 10%, czyli 400 PLN na kolejny okres rozliczeniowy. Jeżeli w tym samym miesiącu wystąpi drugi incydent, łączny kredyt nadal nie przekroczy 50% miesięcznej opłaty.
4 000 PLN × 10%
400 PLN
credit next invoice
4. Wyłączenia SLA
SLA nie obejmuje zdarzeń pozostających poza rozsądną kontrolą DarhimLabs. Obejmuje to siłę wyższą, wojny, akty terroru, klęski żywiołowe, awarie energii lub sieci poza infrastrukturą DarhimLabs, problemy dostawców internetu klienta, błędy urządzeń użytkowników, blokady przeglądarek, konfigurację firewalli klienta, ograniczenia VPN oraz problemy w systemach zewnętrznych, które klient połączył przez integracje.
SLA nie obejmuje również funkcji beta, eksperymentalnych, preview, sandbox, demo mode, środowisk staging, ręcznie tworzonych prototypów, niestandardowych integracji klienta bez osobnego SLA oraz modułów wyłączonych z powodu braku płatności, naruszenia regulaminu, przekroczenia limitów planu, nadużyć, spamu, ataków na konto klienta albo nieprawidłowej konfiguracji API keys, webhook secrets, domen embed lub ustawień OAuth.
Planowane utrzymanie nie jest traktowane jako downtime, jeżeli DarhimLabs poinformuje o nim co najmniej 7 dni wcześniej, a łączny czas planowanego utrzymania nie przekroczy 4 godzin w miesiącu. W pilnych przypadkach bezpieczeństwa DarhimLabs może przeprowadzić emergency maintenance z krótszym wyprzedzeniem, aby ochronić klientów i dane.
- Atak DDoS wymierzony w klienta lub jego domenę embed może zostać wyłączony z SLA.
- Awaria WhatsApp, Meta, Stripe, Twilio lub OpenAI może być incidentem zależności, nie core SLA.
- Funkcje beta i demo nie mają gwarantowanego uptime ani service credits.
- Niedotrzymanie płatności lub naruszenie regulaminu może zawiesić świadczenie SLA.
5. Eskalacja incydentów
Incydenty można zgłaszać przez panel wsparcia, e-mail, CSM lub dedykowany kanał Enterprise. Pierwsza linia supportu przyjmuje zgłoszenie, zbiera podstawowe informacje, przypisuje severity i uruchamia triage. Druga linia obejmuje SRE on-call dla incydentów P1/P2, zespół backend, security lub integracji, w zależności od źródła problemu. Trzecia linia eskalacji obejmuje VP Engineering lub osobę odpowiedzialną za incident commander.
Dla klientów Enterprise CSM jest dostępny w godzinach 8:00-20:00 CET dla koordynacji biznesowej, a on-call działa 24/7 dla P1. CSM nie zastępuje kanału technicznego, ale pomaga zapewnić jasną komunikację: kto pracuje nad problemem, jaki jest workaround, kiedy będzie następna aktualizacja i czy zdarzenie kwalifikuje się do RCA lub service credit.
| Poziom | Kto odpowiada | Zakres | Kiedy |
|---|---|---|---|
| 1. Support | Customer Support | Przyjęcie, triage, komunikacja początkowa | Każde zgłoszenie |
| 2. SRE on-call | SRE / Backend / Security | Diagnoza techniczna, containment, hotfix | P1/P2 i zdarzenia produkcyjne |
| 3. Engineering Leadership | VP Engineering / Incident Commander | Koordynacja cross-team, decyzje o rollbacku i komunikacji | P1, data incident, długie degraded service |
| 4. CSM Enterprise | Customer Success Manager | Komunikacja biznesowa, RCA, follow-up | Enterprise |
6. Status page i historia incydentów
Publiczny status usługi jest dostępny pod adresem status.darhimlabs.pl. Strona statusu pokazuje komponenty takie jak dashboard, API, auth, webhooks, widget runtime, AI providers, Voice, billing i integrations. Klienci mogą subskrybować powiadomienia przez e-mail, RSS, Slack lub webhook, jeżeli dany kanał jest aktywny w planie.
Aktualizacje status page publikujemy przy P1/P2, planowanym maintenance i dłuższych zdarzeniach degraded service. Dla P1 celem jest pierwsza publiczna aktualizacja w ciągu 30 minut od potwierdzenia wpływu, a kolejne aktualizacje co 30-60 minut lub częściej, jeśli sytuacja dynamicznie się zmienia. Po rozwiązaniu istotnego incydentu publikujemy summary, a dla Enterprise możemy przygotować RCA.
7. Programy resilience
DarhimLabs rozwija odporność systemu przez redundancję komponentów, backupy, testy disaster recovery, observability i automatyczne fallbacki. Dla danych produkcyjnych utrzymujemy backupy i procedury odtworzeniowe. RTO dla krytycznych komponentów Enterprise wynosi docelowo 1 godzinę, a RPO 15 minut, chyba że umowa klienta stanowi inaczej lub dany komponent zależy od dostawcy zewnętrznego bez pełnej replikacji.
Failover obejmuje przede wszystkim warstwę aplikacyjną, kolejki, webhook retries, fallbacki modeli AI i ponawianie dostaw wiadomości. Dla usług, które zależą od Meta, Twilio, Stripe, OpenAI, Anthropic albo innych integracji klienta, DarhimLabs może zapewnić degradację kontrolowaną: oznaczenie kanału jako degraded, queue retry, fallback provider lub manualne obejście przez support.
Testy disaster recovery są wykonywane kwartalnie dla kluczowych scenariuszy: odtworzenie backupu, rollback release, awaria providera AI, opóźnione webhooki, utrata dostępu do regionu i przeciążenie API. Wyniki testów są dokumentowane, a działania usprawniające trafiają do roadmapy SRE. Klienci Enterprise mogą otrzymać skrócony raport po NDA.
Multi-region DR
EU primary + EU-DR dla krytycznych warstw.
RTO 1h
Docelowe odtworzenie core dla Enterprise.
RPO 15 min
Docelowa utrata danych ograniczona do krótkiego okna.
Quarterly tests
Kwartalne scenariusze disaster recovery.
SLA, resilience i bezpieczeństwo są powiązane. Zmiany w architekturze bezpieczeństwa opisujemy na stronie Bezpieczeństwo, zasady powierzenia danych w DPA, a warunki biznesowe w Regulaminie. W przypadku konfliktu między dokumentami pierwszeństwo mają indywidualnie podpisane warunki Enterprise, następnie DPA w sprawach danych, a następnie niniejszy SLA.