SDK en 3 lignes
Batching, retry avec backoff, buffer borné, flush à l’arrêt. Middleware Express et contexte async (traceId) inclus.
Installez le SDK, envoyez vos logs et suivez-les en live. Recherche instantanée, alertes Slack / Discord / webhook, sur une architecture taillée pour le volume : ClickHouse, NATS JetStream et SSE.
De l’ingestion à l’alerte, sans assembler cinq outils.
Batching, retry avec backoff, buffer borné, flush à l’arrêt. Middleware Express et contexte async (traceId) inclus.
Les logs apparaissent dans le dashboard en ~1 s via Server-Sent Events, avec filtres appliqués côté serveur.
Plein texte, niveau, service, traceId et champs metadata. Histogramme zoomable, virtualisation pour des millions de lignes.
Règles seuil / absence (heartbeat), Slack, Discord ou webhook signé HMAC. Retries, anti-doublon multi-workers.
Clés API hashées, cache Redis + LRU, rate-limit Lua atomique, protection SSRF, cookies httpOnly, secrets chiffrés.
Suivi de consommation par projet, plans avec limites de volume, débit et rétention appliquées à l’ingestion.
Une clé API est générée ; elle n’est affichée qu’une fois et stockée hashée.
Node, Express ou un simple appel HTTP. Les logs partent par lots en arrière-plan.
Live tail, recherche, histogramme, puis des règles d’alerte vers Slack, Discord ou vos webhooks.
import { Tailowl } from '@tailowl/sdk';
const logger = new Tailowl({
apiKey: process.env.TAILOWL_API_KEY!,
service: 'checkout',
});
logger.info('order created', { metadata: { orderId, amount } });
logger.error(err, { traceId: req.id });« Plus de 10 erreurs sur payments en 5 min », « aucun log du cron depuis 15 min »… Le moteur évalue vos règles en continu, notifie une seule fois même avec plusieurs workers, puis vous prévient quand tout redevient normal.
level ≥ error sur checkout en 5 min (seuil : 10)Dernier : PaymentTimeout: upstream 504 after 3 retriesVoir les logs →Sans carte bancaire pour commencer. Changez de plan à tout moment.
Pour démarrer et les side-projects.
Pour les équipes en production.
Volume illimité, SLA et support.
Les logs sont d’abord écrits dans NATS JetStream (stockage durable). Les workers ré-essaient avec backoff et rattrapent le retard à la reprise, sans perte ni doublon.
Non : les appels sont non bloquants, les logs sont bufferisés en mémoire et envoyés par lots en arrière-plan. Le buffer est borné pour protéger la mémoire.
Oui. Un simple POST JSON sur /v1/logs avec l’en-tête x-api-key suffit, depuis n’importe quel langage.
Chaque requête est signée en HMAC-SHA256 avec un secret propre au canal et horodatée pour empêcher le rejeu.
L’API répond 429 avec un en-tête Retry-After ; le SDK respecte ce délai automatiquement. Vous pouvez changer de plan à tout moment.
Gratuit jusqu’à 100 000 logs par mois.