Le signal manquant n'est pas livré

Le signal manquant est un chemin d'échec, pas un succès mou. Lorsqu'aucun DLR ne revient, que le webhook n'arrive jamais, que le consommateur expire ou que la cellule d'export reste vide, le produit et la finance doivent traiter le silence comme «inconnu» ou «échoué» — jamais comme «Livré». Promouvoir des lignes silencieuses en succès vert ou réglé invente une preuve que le tuyau n'a jamais rien envoyé.

IOSOR est un prépayé en marque blanche. 20 USD financent un pilote qui force l'ouverture des résultats manquants ; une revue douce près de 1 000 USD/mois rend le faux Livré plus bruyant. Cette page traite de l'honnêteté face au silence et au timeout — pas du filtre de contenu (envoyé n’est pas la boîte) ni du retry après DLR échoué (politique de retry DLR échoué sous prepaid). Connexe : Langage de statut partagé pour le produit et la finance, lignes de débit et statut de livraison sur le même ledger, Heartbeat et portes de fumée avant alertes.

Le silence n'est pas une preuve de livraison

Pas de DLR, pas de webhook signé, pas de jointure de corrélation et pas de timestamp d'export signifie «manquant» — pas livré. L'absence de plainte n'est pas une preuve. Préférez «inconnu» ou «manquant» jusqu'à ce qu'un mot terminal arrive ou qu'un propriétaire nommé ferme la ligne par écrit.

Les timeouts doivent rester inconnus ou échoués

Une date limite sans résultat fiable laisse la ligne «inconnue» ou la déplace vers «échoué» par politique — jamais Livré pour vider la file. Les timeouts sont des faits : consommateur bloqué, signature perdue, silence amont ou latence au-delà de la fenêtre de jointure. Un volume doux près de 1 000 USD/mois ne dispense pas d'honnêteté. L'override nécessite un propriétaire, une raison et une nouvelle fumée — pas une puce verte silencieuse.

L'UI et le ledger doivent s'accorder sur le manquant

Les puces produit et les lignes du ledger prépayé doivent partager un seul mot pour le silence. Si l'UI affiche Livré alors que la finance reste dans l'inconnu, la réconciliation mensuelle échoue. Associez le manquant à une réconciliation ouverte ou à un échec terminal — jamais de règlement automatique.

Comment le manquant diffère du filtre et du retry

Le filtre de contenu est un autre échec : le réseau accepte l'envoi tandis que la boîte de réception ne le voit jamais. Le retry commence après un DLR échoué et décide si un autre essai brûle du prépayé. Le manquant commence lorsque le tuyau se tait.

Checklist acheteur pour les signaux manquants

Exigez des webhooks durables qui correspondent à la même ligne de débit. Ne laissez pas l'UI colorer l'inconnu en vert pour apaiser les métriques. Gardez la divergence visible jusqu'à ce que le système enregistre un état terminal vérifié.

Commencez avec IOSOR

Auditez votre console de diffusion et vos écouteurs de webhooks pour garantir que les accusés de réception manquants reviennent à des états inconnus ou ouverts, au lieu de marquer automatiquement les envois comme Livrés. Vérifiez que les retenues sur le grand livre prépayé restent actives jusqu'à l'arrivée d'un événement terminal signé ou qu'une politique de délai explicite transforme l'enregistrement en échec. Définissez des seuils stricts de fenêtre de jointure dans votre pipeline afin que les lignes de messages non confirmées déclenchent des retenues de réconciliation plutôt qu'un nettoyage prématuré de la file d'attente.

À retenir — IOSOR

Les tentatives d'envoi non confirmées sans accusé de réception explicite ou sans webhook signé ne doivent jamais être marquées comme Livrées.