Planification · Exécution
Vos endpoints, appelés
à la minute.
Nous appelons votre endpoint selon le planning ; vous vous concentrez sur le handler. Un vrai constructeur de requêtes — pas une simple saisie d'URL — avec réessais, application des timeouts et un journal d'exécution complet pour chaque run.
Offre gratuite — sans carte bancaire.
Sans SteadyCron
# /etc/cron.d/invoices
0 9 * * 1-5 deploy /app/send_invoices.sh
# Exit code: unknown.
# Retries: none.
# Logs: rotated.
# Did it run? Check manually.Avec SteadyCron
✓ récupéré après 1 réessai — alerté sur l'échec, résolu à la récupération
Le problème
Le cron système est un mensonge que vous avez accepté
Il s'exécute et oublie. Aucun réessai. Aucun timeout. Aucun journal d'audit. Aucune alerte quand le script échoue, dépasse le délai ou s'arrête complètement.
Échecs silencieux
Votre cron se déclenche, votre script plante, personne ne s'en aperçoit. La sauvegarde DB qui ne tourne plus depuis six semaines. Le rapport qui est vide depuis le déploiement.
exit 1 # ← zero alerts Aucun réessai ni timeout
Un problème réseau passager fait échouer le job définitivement. Ou un job reste bloqué indéfiniment, occupant un slot cron pendant que la mémoire du serveur grimpe.
SIGKILL? never heard of it Syntaxe cron désastreuse
Chaque équipe a un README avec une légende pour expliquer ce que signifie 0 4 * * 1. Puis quelqu'un le modifie mal et le job tourne toutes les minutes à 4h du matin.
0 4 * * 1 # ??? Aucun journal d'audit
"Le job de facturation a-t-il tourné mardi dernier ?" Vous vérifiez les logs. Il n'y a pas de logs. cron.log a été rotaté il y a six jours.
grep -i invoice /var/log/cron.log Comment ça marche
Définissez une fois. Tourne indéfiniment.
Pas de daemon cron à surveiller. Pas de rotation de logs à gérer. SteadyCron prend en charge l'exécution — du début à la fin.
Définir le job
Configurez l'URL, la méthode, les headers, le body, le planning et le fuseau horaire en deux minutes. Ajoutez des réessais, un timeout et des variables de template. Ou déclarez-le en code et appliquez-le depuis CI.
POST /v1/invoices/send 0 9 * * 1-5 Europe/Berlin Nous envoyons la requête
À l'heure planifiée, SteadyCron envoie la requête HTTP avec vos headers et votre body exacts. L'heure d'été est gérée correctement. Si le code de réponse est éligible à un réessai, nous réessayons avec backoff exponentiel.
POST → 200 OK 312ms attempt 1/1 Inspecter chaque exécution
Chaque run est journalisé : statut de réponse, body, headers, durée et numéro de tentative. Un run qui a échoué puis récupéré lors d'un réessai est différent de celui qui a épuisé toutes les tentatives.
→ success attempt 2/3 847ms total Constructeur de requêtes
Un vrai constructeur de requêtes,
pas une simple saisie d'URL
Commencez par un nom, une URL et un planning. Choisissez une expression cron ou un intervalle — un aperçu en direct des prochains runs vous montre les heures d'exécution exactes avant d'enregistrer, sans surprises à 3h du matin.
Choisissez n'importe quelle méthode HTTP. Ajoutez des headers de requête — Authorization, Content-Type, ou tout ce qu'attend votre endpoint. Attachez un body JSON pour les jobs POST et PUT, avec coloration syntaxique en direct et validation qui détecte les payloads malformés avant leur envoi.
Pour les cas avancés : insérez des variables {{template}} n'importe où dans l'URL, les headers ou le body. Elles sont résolues côté serveur au moment du déclenchement et ne sont jamais stockées dans vos scripts — utile pour les tokens d'API, les identifiants de compte, ou toute valeur qui varie selon les environnements. La planification par fuseau horaire au niveau du job signifie que "jours ouvrés à 09:00 Berlin" s'exécute à 09:00 Berlin, même lors des transitions DST.
Request
Configure the HTTP request sent on each execution. Use
{{variable}}
for template substitution.
Headers
{
"account_id": "{{accountId}}",
"amount_cents": 4900,
"send_email": true
}✓ Valid JSON
Schedule
When it runs — cron or interval, with DST-correct timezones and a live next-runs preview.
Cron expression
Weekdays at 09:00
Timezone
Next runs
Ce que nous enregistrons
Quatre résultats possibles pour une exécution
Chaque résultat est distinct, journalisé et affiché dans le tableau de bord avec sa propre couleur et son propre libellé.
Succès
L'endpoint a répondu avec un statut 2xx dans le timeout configuré. Exécution terminée, réponse complète journalisée.
Échec
L'endpoint a renvoyé un statut non-2xx sur toutes les tentatives, ou la connexion a échoué. Chaque tentative est une entrée de journal distincte.
Timeout
L'endpoint n'a pas répondu dans le timeout par job. La requête est abandonnée proprement — aucune connexion zombie.
Ignoré
Le run précédent était encore en cours au moment du déclenchement suivant. Le garde anti-chevauchement a empêché une exécution concurrente.
Fiabilité
Conçu pour les jobs qui ne doivent pas échouer en silence
Les contrôles que vous auriez autrement codés manuellement autour du cron système sont ici une configuration de premier plan.
Réessais avec backoff exponentiel
Configurez jusqu'à 5 réessais avec backoff exponentiel. Choisissez exactement quels codes de statut HTTP déclenchent un réessai — ainsi un 404 reste un échec définitif mais un 503 obtient une nouvelle chance.
retry_on: [429, 503, 502]
max_retries: 3 backoff: 30s Application du timeout par job
Si votre endpoint est bloqué — requête DB lente, API amont dégradée — SteadyCron abandonne la requête après le timeout configuré. Aucune connexion zombie, aucune fuite de ressources silencieuse.
timeout_seconds: 30
# error_kind: request_timeout Garde anti-chevauchement
Si le run précédent n'est pas terminé quand le prochain déclenchement est prévu, nous ignorons le nouveau run plutôt que d'empiler des requêtes concurrentes sur votre endpoint. Prévient les défaillances en cascade sur les jobs lents.
skip_if_still_running: true
# status: skipped Journal d'audit
Chaque run, entièrement journalisé
Statut de réponse, body, headers, durée et numéro de tentative — stockés pour chaque exécution. Plus jamais "le job de facturation a-t-il tourné mardi dernier ?" et un haussement d'épaules.
Les runs échoués qui ont récupéré lors d'un réessai sont différents des runs qui ont épuisé toutes les tentatives. Chaque tentative est sa propre entrée de journal avec son propre timing et code de statut, afin que vous puissiez voir exactement où les choses ont mal tourné.
invoice-send · journal d'exécution
Une plateforme, trois métiers
Exécution HTTP
Vous êtes iciAppelez vos endpoints à l’heure prévue — réessais, délais et journaux complets.
Surveillance heartbeat
Surveillez les tâches que vous exécutez partout ; soyez alerté dès qu’une se tait.
Cron as code
Déclarez chaque tâche, moniteur et alerte en YAML ou Terraform.
Arrêtez de vous demander si votre job a tourné.
Définissez le job une fois. Nous gérons l'exécution, les réessais, les timeouts et le journal d'audit. Vous gérez le handler.
- Offre gratuite — sans carte bancaire
- Hébergé en UE, RGPD natif
- 5 tâches HTTP dans l'offre gratuite