OPUBLIKOWANO: 11 lutego 2026
Największa zmiana, jaką daje OpenClaw w firmie, nie polega na tym, że „AI umie pisać”. Polega na tym, że możesz zbudować asystenta, który pracuje w rytmie organizacji: codziennie rano robi krótkie poranne podsumowanie, w poniedziałek o 8:00 wysyła raport tygodniowy, a raz na godzinę sprawdza systemy i alarmuje tylko wtedy, gdy coś się psuje.
Do tego służy cron w OpenClaw. To harmonogram, który uruchamia zadania automatycznie o ustalonej porze – bez Twojego udziału. W przeciwieństwie do klasycznego crona na Linuksie, zadaniem nie musi być skrypt. Zadaniem może być „agent turn” (tura agenta): AI dostaje polecenie, może użyć narzędzi, policzyć wskaźniki, wygenerować raport i wysłać go na kanał.
W tym artykule pokazuję, jak używać crona w OpenClaw pragmatycznie: jakie typy harmonogramów mają sens, jak projektować zadania, żeby były stabilne i tanie, oraz kiedy zamiast crona lepiej użyć heartbeatów.
- Czym jest cron w OpenClaw
- Kiedy cron ma sens (a kiedy nie)
- Typy harmonogramów: cron vs „co X minut” vs zadania jednorazowe
- Przykłady: poranne podsumowanie, raport tygodniowy, monitoring, backup
- Jak projektować zadania w cronie, żeby nie robiły chaosu
- Cron vs heartbeats: prosta reguła
Czym jest cron w OpenClaw
Jeśli znasz Linuksa, znasz też klasycznego crona: wpis w harmonogramie mówi „o 03:00 uruchom backup”. OpenClaw robi podobnie, ale zamiast uruchamiać wyłącznie polecenia w powłoce (shellu), może uruchomić zadanie, w którym AI analizuje dane, używa narzędzi i generuje wynik.
To ważne rozróżnienie. W wielu firmach najdroższa jest nie sama automatyzacja (np. skopiowanie pliku), tylko myślenie i selekcja: co jest ważne, gdzie jest ryzyko, co wymaga decyzji. Cron w OpenClaw pozwala automatyzować właśnie ten etap.
Druga ważna rzecz: zadania crona powinny być samowystarczalne. Nie powinny polegać na „pamiętaniu” kontekstu rozmowy. Jeśli cron ma dowozić realną wartość, musi mieć jasno opisane wejście, cel i format wyjścia.
Kiedy cron ma sens (a kiedy nie)
Cron ma sens, gdy liczy się precyzja. Jeśli raport ma przyjść w poniedziałek o 8:00, to heartbeat odpalany „mniej więcej co pół godziny” nie wystarczy. Cron ma też sens, gdy zadanie jest powtarzalne i dowozi wartość niezależnie od tego, czy akurat pamiętasz, żeby o nim pomyśleć.
Cron nie ma sensu, gdy zadanie wymaga bieżącego kontekstu rozmowy albo gdy powinno milczeć, jeśli nic się nie zmieniło. W takich przypadkach lepsze są heartbeats: asystent sprawdza świat i decyduje, czy w ogóle przerywać.
Najczęstsze sensowne zastosowania crona w firmie to raporty, przypomnienia, rytmy operacyjne (np. piątkowy przegląd projektów) oraz monitoring z ustalonym harmonogramem.
Typy harmonogramów: cron vs „co X minut” vs zadania jednorazowe
W praktyce masz trzy tryby – i każdy pasuje do innego problemu.
Pierwszy to klasyczne wyrażenie crona (cron expression), gdy chcesz precyzyjny dzień i godzinę. Drugi to harmonogram „co X minut”, gdy zadanie ma być wykonywane regularnie, ale nie musi być przywiązane do kalendarza. Trzeci to zadanie jednorazowe: przypomnienie „za 20 minut” albo raport „jutro o 9:00”.
To nie są detale techniczne. To trzy różne modele oczekiwań. Jednorazowe przypomnienie ma być niezawodne i krótkie. Raport tygodniowy ma być powtarzalny, porównywalny i mieć stały format. Monitoring (np. „co 10 minut”) musi mieć progi i zasady eskalacji – inaczej zamieni się w spam.
Przykłady: poranne podsumowanie, raport tygodniowy, monitoring, backup
Najprostszy przykład to poranne podsumowanie dnia. Tu wartością jest selekcja informacji: asystent zbiera sygnały (kalendarz, skrzynka, zadania) i zamienia je w krótką listę priorytetów.
Drugi przykład to raport tygodniowy. W tym scenariuszu ważne jest porównanie do poprzedniego tygodnia oraz sugerowane działania. Raport, który tylko opisuje dane, zostaje ciekawostką. Raport, który proponuje 1–2 działania, staje się narzędziem decyzji.
Trzeci przykład to monitoring. Cron może uruchamiać sprawdzenia (np. dostępność strony, błędy w logach) i wysyłać alert tylko wtedy, gdy przekroczysz próg. Kluczowe są progi i kontrola „szumu”.
Czwarty przykład to backup. Tu cron jest klasyczny: precyzja czasu i jasna procedura. Ale nawet tu AI może pomóc, np. podsumowując, czy backup się udał oraz czy pojawiły się anomalie.
| Zadanie | Harmonogram | Co ma wyjść | Guardrail |
| Poranne podsumowanie | Codziennie rano | Krótka lista priorytetów | Maks. 200–300 słów |
| Raport tygodniowy | Poniedziałek 8:00 | KPI + porównanie + 1–2 działania | Stały format |
| Monitoring | Co 10–30 min | Alerty tylko powyżej progu | Progi + brak komunikatu „nic nowego” |
| Backup | Noc | Potwierdzenie lub alarm przy błędzie | Powiadomienia tylko przy błędach |
Jak projektować zadania w cronie, żeby nie robiły chaosu
Dobre zadanie w cronie jest jak dobry proces: ma jasny cel, definicję „gotowe” i stały format. Jeśli zmieniasz format co tydzień, tracisz możliwość porównywania. Jeśli prosisz o „sprawdź wszystko”, dostaniesz ścianę tekstu, której nikt nie czyta.
Trzy praktyczne zasady, które naprawdę działają:
Po pierwsze: ogranicz zakres. Jedno zadanie = jeden rezultat. Jeśli chcesz pięć rzeczy, zrób pięć zadań albo jedno zadanie, które ma jasny, krótki format.
Po drugie: mierz koszt. Cron uruchamiany co 5 minut potrafi spalić budżet bez proporcjonalnej wartości. W wielu firmach „co 30 minut” jest w praktyce równie dobre.
Po trzecie: oddziel odczyt (read) od zapisu (write). Na start cron powinien generować raporty, drafty i rekomendacje. Automatyczne operacje write (np. wysyłka e-maili) dodajesz dopiero, gdy zbudujesz zaufanie i masz walidację.
Cron vs heartbeats: prosta reguła
Jeśli zależy Ci na dokładnej godzinie i powtarzalnym rytmie – użyj crona. Jeśli zależy Ci na „patrolu” i decyzji, czy w ogóle przerywać – użyj heartbeats.
Najlepsze wdrożenia łączą oba mechanizmy: cron robi raporty o stałych porach, a heartbeats pilnują spraw zmiennych, które wymagają selekcji.
Potrzebujesz automatyzacji cyklicznych?