(Job cron · Nautilus)
Hai raggiunto il limite dello scheduler della tua piattaforma? Nautilus chiama qualsiasi URL pubblico con la pianificazione cron che imposti, fino a una volta al minuto. Una chiamata fallita viene ritentata, ogni tentativo è registrato e le pianificazioni si impostano tramite un'API invece che in un file di configurazione. Le pianificazioni girano in UTC.
curl -X POST https://api.vernesoft.com/v1/clockwork/jobs \
-H "Authorization: Bearer vrn_clockwork_•••" \
-d '{"name":"billing","schedule":"0 0 1 * *","url":"https://api.yourdomain.com/billing"}'(Dove cron si ferma)
Un crontab va bene su una macchina, e lo scheduler di una piattaforma va bene dentro la sua piattaforma. I guai cominciano al confine: il piano gratuito che consente un'esecuzione al giorno, il secondo server che lancia due volte lo stesso job, il guasto che nessuno ha visto.
Crontab e scheduler di piattaforma
Job cron in Nautilus
(Funzionalità principali)
(01)
La pianificazione vive da noi, non in ogni istanza della tua app, quindi scalare la tua app non può moltiplicarla. Da parte nostra, ogni esecuzione dovuta viene riservata nel database prima di partire, così un secondo worker che vede lo stesso job lo trova già preso.
(02)
Crea, metti in pausa, modifica ed elimina pianificazioni tramite l'API, oppure pianifica un'attività singola per un orario preciso. Se i tuoi clienti definiscono le proprie attività ricorrenti nel tuo prodotto, il tuo backend crea il job quando salvano.
(03)
Un'esecuzione fallita riceve fino a tre tentativi: il primo, poi nuovi tentativi dopo uno e cinque minuti. Lo stato dei nuovi tentativi vive con il job e non in memoria, così un nuovo tentativo in sospeso sopravvive al riavvio del worker o a un deploy.
(04)
Lo scheduler si sveglia una volta al minuto e avvia ciò che è dovuto, così un job impostato per le 09:00 parte al primo controllo alle 09:00 o dopo, non in un punto qualsiasi dell'ora. Non c'è un campo dei secondi, e ogni pianificazione gira in UTC.
(05)
Ogni tentativo è registrato con l'ora di inizio, la durata, lo stato HTTP restituito dal tuo endpoint e il body della risposta, oppure l'errore se la chiamata non si è mai connessa. La cronologia è conservata per la finestra del tuo piano, indicata nella pagina dei prezzi.
(06)
Espressioni cron standard a 5 campi, risolte in UTC: non ci sono fusi orari né macro abbreviate come daily o hourly. Una pianificazione che limita sia il giorno del mese sia il giorno della settimana viene rifiutata invece di essere indovinata, e lo stesso vale per una che non può mai scattare.
(Parte di Nautilus)
I job cron sono una parte di Nautilus, sullo stesso account e sulla stessa dashboard di accesso e consegna dei webhook. Lo scheduler è codice nostro. Accesso e consegna dei webhook girano su motori open source che potresti ospitare tu; questa parte non viene con te se te ne vai. Ciò che viene con te: ogni job e ogni esecuzione è leggibile tramite l'API.
(Esperienza sviluppatore)
Dagli un'espressione cron e un URL, con un SDK ufficiale o una semplice richiesta HTTP. Un'attività singola prende invece un timestamp UTC.
curl -X POST https://api.vernesoft.com/v1/clockwork/jobs \
-H "Authorization: Bearer $VERNE_CLOCKWORK_KEY" \
-H "Content-Type: application/json" \
-d '{
"name": "Monthly Billing Run",
"schedule": "0 0 1 * *",
"url": "https://api.yourdomain.com/billing/process",
"method": "POST",
"body": "{\"batch\":\"auto\"}"
}'(FAQ)
La pianificazione vive da noi, quindi aggiungere istanze della tua app non cambia nulla. Da parte nostra, ogni esecuzione dovuta viene riservata con un aggiornamento condizionale nel database prima che parta qualcosa: un secondo worker che vede lo stesso job trova la riga già avanzata e non fa nulla. Questo ti dà un innesco per slot pianificato. La consegna in sé è at-least-once, perché un tentativo fallito viene ritentato, quindi rendi il tuo endpoint idempotente e usa l'header X-Clockwork-Attempt per proteggere gli effetti collaterali.
Ogni esecuzione riceve fino a tre tentativi: il primo, poi nuovi tentativi dopo uno e cinque minuti. Gli errori di rete, i 5xx e i 429 vengono ritentati; le altre risposte 4xx no, perché un nuovo tentativo identico riceverebbe la stessa risposta. Ogni tentativo attende fino a 30 secondi una risposta, e i redirect non vengono seguiti, quindi indica l'URL finale. Ogni tentativo è registrato con la risposta restituita, e un nuovo tentativo in sospeso sopravvive al riavvio del worker.
Sì. Oltre alle espressioni ricorrenti puoi pianificare un'attività singola per un timestamp UTC, per esempio l'invio di un'email 24 ore dopo la registrazione. Viene presa in carico al controllo una volta al minuto dello scheduler, come tutto il resto qui.
Sì. Un job è una chiamata HTTP a un URL pubblico, quindi può puntare a una route del tuo deployment su Vercel, con gli header che servono per superare i tuoi controlli, fino a una volta al minuto. La funzione continua a girare su Vercel, quindi valgono i limiti di durata e di utilizzo di Vercel; Nautilus fa solo la chiamata, e quelle esecuzioni non contano nella tua quota di richieste. Per la cronaca, la documentazione di Vercel (consultata il 3 ottobre 2026) include il cron su ogni piano, anche Hobby, ma limita Hobby a un'esecuzione al giorno con precisione solo di un'ora; Pro gira al minuto. Gli altri si fermano ai propri confini: pg_cron raggiunge solo ciò che il tuo database può raggiungere, e una pianificazione di GitHub Actions può partire in ritardo con carico elevato, secondo la sua stessa documentazione.
Crea un job differito a un minuto da ora con POST /v1/clockwork/delayed e guardalo nel registro delle esecuzioni. Non c'è ancora un pulsante per eseguire subito. Un'esecuzione singola usa lo stesso worker e gli stessi registri di una ricorrente.
Sì, senza carta. Clockwork non usa la tua quota di richieste: né le esecuzioni pianificate né le chiamate all'API di Clockwork vengono conteggiate. Ciò che ogni piano limita è il numero di job attivi contemporaneamente: il piano gratuito consente 10 job ricorrenti e 100 job differiti in attesa, Starter 100 e 1.000, Pro 1.000 e 10.000. Starter costa 19 € e Pro 79 € al mese; la pagina dei prezzi ha l'elenco aggiornato.
Non oggi. Nulla invia un avviso quando un'esecuzione fallisce. Ogni tentativo è registrato con lo stato e il body ricevuti, e puoi leggere il registro nella dashboard o interrogare l'endpoint delle esecuzioni, così un controllo tuo può dare l'allarme.
(Inizia)
I job cron sono una parte di Nautilus: lo stesso account e la stessa dashboard di accesso e consegna dei webhook.
Quando non ti serve
Se fai girare una applicazione su una macchina, crontab va bene e conviene tenerlo. Lo stesso vale per il lavoro che non lascia mai la sua piattaforma: Vercel Cron è adatto a una funzione Vercel, pg_cron è adatto a un job che tocca solo il tuo database Supabase, e una pianificazione GitHub Actions basta per un'attività notturna che può permettersi di partire in ritardo.
Nautilus si guadagna il suo posto al confine in cui questi si fermano, e quel confine arriva prima di quanto si pensi. La seconda istanza, dove due copie dello stesso crontab lanciano due volte la stessa fatturazione. Il job che deve chiamare un servizio su un altro host. La pianificazione che i tuoi clienti impostano dalla tua dashboard. Il piano gratuito che lancia un job giornaliero in un punto qualsiasi dell'ora. L'esecuzione che è fallita alle 03:00 senza lasciare traccia.
Questi cinque sono i casi a cui risponde Nautilus: un'esecuzione per pianificazione indipendentemente da quante istanze distribuisci, qualsiasi URL pubblico su qualsiasi host, pianificazioni create e annullate tramite un'API, precisione al minuto su ogni piano e un registro di ogni tentativo con la risposta restituita. Le esecuzioni pianificate non contano nella tua quota di richieste, e il piano gratuito consente 10 job ricorrenti attivi.