Plik pod https://hellocron.com/hellocron.sh zawsze serwuje najnowszą wersję z listy poniżej. Starsze wpisy to historia zmian, nie są trzymane jako osobne pliki do pobrania. Użyj hellocron update, aby przejść na najnowszą, albo hellocron version, aby sprawdzić zainstalowaną.
Interaktywny discover-server-apps proponuje zapis wypisanego pliku do /etc/cron.d. Wymaga roota, zapisuje atomowo z uprawnieniami 0644, a przed zastąpieniem istniejącego pliku pyta osobno i zachowuje ukrytą kopię. --yes, -o i przekierowany stdout zachowują dotychczasowe działanie.
v1.6.0-260922 (przed wydaniem)
Nowa komenda discover-server-apps: wykrywa usługi zainstalowane na hoście (nginx, Apache, certbot, PostgreSQL, MySQL/MariaDB, Redis, MongoDB) i czy działają, pozwala zaznaczyć sprawdzenia na liście, tworzy odpowiadające im monitory kondycji serwera przez API presetów i wypisuje plik crona. Plik crona to jedyna rzecz na stdout, więc hellocron discover-server-apps --yes > /etc/cron.d/hellocron-server-health to kompletna instalacja; --items, --all, --host, --backup-dir, --disk-threshold, --dry-run i -o obsługują skrypty i provisioning. Wymaga klucza zarządzania i planu z config as code.
apply i export podają prawdziwy status HTTP, gdy żądanie się nie uda. Dotąd każdy błąd, także odrzucony klucz albo problem walidacji, zgłaszały jako „brak połączenia”.
v1.5.4-260914 (przed wydaniem)
run zachowuje oryginalną maskę uprawnień zadania. Kolory ANSI i pozostałe znaki kontrolne nie psują już JSON-a pinga.
discover zachowuje cytowane znaki # i backslashe, wykonuje przypisania zmiennych przez shell oraz bezpiecznie cytuje nazwy projektów i ścieżkę klienta.
Opcje bez wartości natychmiast zwracają błąd. configure zwraca niepowodzenie, gdy nie może zapisać konfiguracji lub ustawić jej uprawnień.
v1.5.3-260913 (aktualna)
Wydana 2026-09-13. Klient mówi o limicie planu, ale nigdy nie wywraca z tego powodu zadania.
Stan kwoty czytany z nagłówków odpowiedzi każdego pingu i zgłaszany na stderr: zbliżasz się do limitu, przekroczyłeś go albo monitoring jest wstrzymany, za każdym razem z datą wyzerowania licznika. Wyczerpanie kwoty nigdy nie zmienia kodu wyjścia i nigdy nie psuje zadania. O to tu właśnie chodzi: ping leci z linijki curl w crontabie, więc odpowiedź błędem sprawiłaby, że cron uzna poprawnie wykonane zadanie za nieudane i wyśle o tym maila. Nasz problem rozliczeniowy nie może stać się czyjąś awarią na produkcji.
Komunikaty z żądania pingu w ogóle docierają do terminala. Wcześniej całe wyjście trafiało do zmiennej, której nikt nie czytał, więc każde ostrzeżenie znikało bez śladu.
Dla instalacji self-hosted i starszych serwerów nic się nie zmienia: brak nagłówków kwoty znaczy brak komunikatów.
v1.5.2-260912
Wydana 2026-09-12. discover rozumie crontaby, które naprawdę istnieją, a doctor odpowiada, czy klient jest aktualny.
doctor mówi, czy zainstalowany klient jest tym aktualnym. Pyta o opublikowaną wersję, przy nowszej podaje jej numer i polecenie update; czekająca aktualizacja jest ostrzeżeniem, a nie błędem diagnostyki. Gdy host z plikiem do pobrania jest nieosiągalny, linia mówi wprost, że nie dało się sprawdzić, zamiast twierdzić cokolwiek. --no-update-check pomija to zapytanie.
Nazwy dni i miesięcy są przyjmowane: 5 4 * * sun, 0 8 * * MON i 30 2 1 JAN * to zwykła składnia crontab(5), a były pomijane bez słowa, więc zaplanowane nimi zadania zostawały bez monitoringu.
Komenda zbudowana ze składni shella (&&, ||, ;, potok, przekierowanie, if) idzie do /bin/sh -c, zamiast być uruchamiana wprost. run nie jest shellem: test -x /usr/sbin/anacron || { cd / && run-parts /etc/cron.daily; } było monitorowane tylko do pierwszego operatora, a część wykonująca pracę działała poza monitorem. Końcowe >/dev/null 2>&1 zostaje na zewnątrz, żeby wyciszyć też komunikaty samego klienta.
Crontaby systemowe są obsłużone: w /etc/crontab i /etc/cron.d/* szóste pole to użytkownik, na którego prawach działa zadanie. Rozpoznawane po nazwie pliku albo wymuszane przez --system / --user-crontab. Użytkownik zostaje tam, gdzie cron go oczekuje, i przestał być nazwą monitora, więc cały katalog zadań nie trafia już jako root, root-5ef365, root-913b85.
Nazwy monitorów biorą się z programu, który wykonuje pracę, a nie z otaczającej go instalacji shellowej: run-parts-cron-daily, debian-sa1, sessionclean zamiast test, command, cd, if. Tabulatory między polami harmonogramu są obsługiwane, a @midnight jest rozpoznawane obok pozostałych skrótów.
Wyrażenia, których cron nie wczyta, są pomijane zamiast proponowane: rozszerzenia Quartz (0 0 14W * *, 0 0 * * 6#5, LW), szóste pole harmonogramu, pełne nazwy dni (friday), zwykłe literówki. Odrzucony plik crontaba pociąga za sobą wszystkie pozostałe zadania, więc brak propozycji jest bezpieczniejszą odpowiedzią.
v1.5.1-260912
Wydana 2026-09-12. Jedno pytanie przy konfiguracji i nazwy, które da się czytać w panelu.
configure pyta o klucz ingest i o nic więcej. Adres API jest zaszyty w kliencie, więc w pliku konfiguracyjnym zostaje sam klucz. configure --api-key ck_xxx --project nazwa ustawia wszystko bez pytania, a --advanced nadal pyta o adres API i endpoint pinga przy instalacji self-hosted albo na staging.
run oddaje wyjście komendy na tym strumieniu, z którego przyszło. Wcześniej było przechwytywane do pinga i nigdy nie drukowane, przez co linia crontaba dopisująca do pliku logu po cichu zapisywała pustkę, a cron przestawał wysyłać maila o awarii.
discover buduje nazwy monitorów z adresu URL albo nazwy skryptu, a nie z pierwszego słowa linii: fakturex-fcron zamiast curl-16f0fd. Nazwy są czyszczone do zestawu znaków, który przyjmuje API, więc kropka w nazwie skryptu nie tworzy już monitora, którego każdy ping jest odrzucany. Krótki hash dochodzi tylko wtedy, gdy dwa zadania miałyby tę samą nazwę.
Podpowiedzi pokazują skrót zapisanego klucza zamiast całości.
discover --host-prefix dokleja krótką nazwę hosta na początek każdej wygenerowanej nazwy, na wypadek jednego crontaba wdrożonego na kilku serwerach. Domyślnie nazwy pozostają per zadanie, bo nazwy monitora nie da się później zmienić, a serwer można przezwać.
Raportowany host można przypiąć wpisem hostname= w pliku konfiguracyjnym albo zmienną HELLOCRON_HOSTNAME, co ma znaczenie w kontenerach, gdzie hostname to losowy hex. doctor wypisuje host, który zostanie zaraportowany.
v1.4-260911
Wydana 2026-09-11. Nowa nazwa, nowy adres.
Skrypt nazywa się hellocron.sh i jest pobierany z https://hellocron.com/hellocron.sh; hellocron update sprawdza ten adres.
Pliki konfiguracyjne to ~/.hellocron.conf i ~/.hellocron-management.conf; zmienne środowiskowe to HELLOCRON_API_KEY, HELLOCRON_MANAGEMENT_KEY, HELLOCRON_PANEL_URL.
Domyślne endpointy wskazują api.hellocron.com i app.hellocron.com.
Nowy nagłówek hello:cron w help, doctor i version.
v1.3-260727
Wydana 2026-07-27. Config as code z wiersza poleceń.
hellocron export pobiera wszystkie monitory z konta jako jeden plik bundle.
hellocron apply -f monitors.json doprowadza konto do stanu z tego pliku, a --dry-run pokazuje zmiany przed ich wprowadzeniem. Apply nigdy nie usuwa: monitory, których nie ma w bundle’u, są raportowane jako osierocone i zostają nietknięte.
hellocron configure --management-key zapisuje klucz Management API w ~/.hellocron-management.conf (uprawnienia 600), osobno od ~/.hellocron.conf. Klucz ingest z natury leży na każdym monitorowanym serwerze, a klucz zarządzający potrafi usunąć monitor razem z historią, więc oba nigdy nie dzielą jednego pliku. HELLOCRON_MANAGEMENT_KEY ma pierwszeństwo i jest właściwym wyborem w CI.
Pomylenie kluczy jest teraz wykrywane lokalnie, z wyjaśnieniem, zamiast gołym 401: apply/export odrzucają klucz ingest (ck_), a pingi odrzucają klucz zarządzający (mk_).
hellocron doctor raportuje klucz zarządzający i uprawnienia jego pliku konfiguracyjnego, jeśli istnieje.
v1.2-260704
Wydana 2026-07-04. Pierwsze publiczne wydanie, serwowane pod adresem pobierania.
Pingi cyklu życia zadań (run, complete, fail, skip) oraz opakowywanie komend z automatycznym raportowaniem kodu wyjścia.
Interaktywna konfiguracja przez hellocron configure, z ustawieniami zapisywanymi w ~/.hellocron.conf.
Wykrywanie zadań cron przez hellocron discover: znajduje istniejące zadania i generuje konfigurację monitoringu.
Samo-aktualizacja przez hellocron update (oraz update --check): weryfikacja SHA-256, sprawdzenie składni i kopia .bak przed podmianą.
Diagnostyka środowiska przez hellocron doctor.
Konfigurowalne limity czasu, tryb verbose, przełącznik telemetrii i domyślny projekt.