Les 3 niveaux d'erreur, le plan B par composant, la correction, et le post-mortem.

Gestion des erreurs

Tout casse a un moment. La question n'est pas "si" mais "quand". Agent OS categorise les erreurs en 3 niveaux et a un plan B pour chaque composant.

Les 3 niveaux d'erreur

Niveau	Icone	Signification	Delai de reaction	Notification
WARNING	Jaune	Anomalie detectee, pas de perte	Heures	Telegram (brief suivant)
ERROR	Orange	Echec d'une action, impact limite	< 1 heure	Telegram (immediat)
CRITICAL	Rouge	Systeme down ou perte de donnees	< 15 min	Telegram + SMS

Exemples par niveau

WARNING :

Un cron a mis 2x plus de temps que d'habitude
Un agent a consomme plus de tokens que prevu
Engagement social en baisse de 20%
Espace disque a 80%

ERROR :

Un cron a echoue
Un agent ne repond plus
Une API retourne des erreurs
Un deploiement a echoue

CRITICAL :

Serveur principal down
Base Notion inaccessible
Perte de connexion Telegram (pas de canal de communication)
Stop-loss non execute (trading)
Sauvegarde corrompue

Plan B par composant

OpenClaw (runtime)

Probleme	Detection	Plan B
Gateway crash	Health check (CRON-001)	Auto-restart via systemd
Agent bloque	Timeout depasse	Kill + restart de l'agent
Queue pleine	Monitoring memoire	Purge des taches anciennes
Config corrompue	Validation au reload	Rollback Git automatique

Telegram (communication)

Probleme	Detection	Plan B
Bot deconnecte	Pas de delivery confirm	Retry 3x puis alerte email
Rate limit	HTTP 429	Backoff exponentiel
API down	Connection timeout	Stocker les messages, envoyer au retour

Notion (donnees)

Probleme	Detection	Plan B
API indisponible	Connection error	Cache local, sync au retour
Rate limit	HTTP 429	Batch les requetes
Page corrompue	Validation schema	Restaurer depuis backup

Trading (Hyperliquid)

Probleme	Detection	Plan B
API down	Connection timeout	Stop-loss on-chain restent actifs
Ordre rejete	Error response	Retry avec parametres ajustes
Position a risque	PnL monitoring	Alerte CRITICAL immediate

Infra (serveur)

Probleme	Detection	Plan B
Serveur down	CRON-001	Alerte + tentative auto-restart
Disque plein	Monitoring espace	Purge logs anciens + alerte
RAM saturee	Monitoring memoire	Kill processes non essentiels
SSL expire	CRON-011	Renouvellement auto (Cloudflare)

Processus de correction

1. Detecter

Les crons de monitoring detectent automatiquement. Le CEO categorise le niveau.

2. Notifier

Le CEO envoie une alerte sur Telegram avec :

Le niveau (WARNING/ERROR/CRITICAL)
Le composant affecte
L'impact
L'action recommandee

ERROR : Cron CRON-004 (Social Pulse) echoue.
Cause : API Twitter rate limit.
Impact : Pas de scan engagement aujourd'hui.
Action : Retry automatique dans 1h.
Intervention requise : Non.

3. Corriger

Type	Qui corrige	Comment
Auto-corrigeable	Le systeme	Retry, restart, fallback
Manuelle simple	Le CEO	Commande de correction
Manuelle complexe	L'utilisateur	Intervention directe

4. Verifier

Apres correction, le CEO verifie que tout est revenu a la normale.

openclaw health check --verbose

Post-mortem

Pour chaque erreur ERROR ou CRITICAL, un post-mortem est genere.

Format du post-mortem

Post-mortem : [ID de l'incident]
Date : 2026-04-02
Niveau : ERROR
Composant : Trading Agent
Duree : 45 min

Chronologie :
- 14:30 : Ordre d'achat rejete par Hyperliquid
- 14:31 : Retry automatique echoue
- 14:35 : Alerte CEO
- 14:40 : Alerte utilisateur
- 14:50 : Investigation manuelle
- 15:15 : Cause identifiee (margin insuffisante)
- 15:15 : Resolution (ajout margin)

Cause racine : Le trading agent n'a pas verifie la margin disponible avant l'ordre.
Action corrective : Ajouter un check de margin pre-ordre.
Statut : Corrige et deploye.

!!! tip "Pas de blame, que des faits" Le post-mortem analyse la cause, pas le coupable. L'objectif : que l'erreur ne se reproduise pas.

Lecture liee

Routine quotidienne pour le flux d'alertes normal
Couts quand les erreurs ont un impact financier
KPIs pour mesurer le taux d'erreur

Gestion des erreurs

On this page