Status
What happens when something is down.
Loadline sits between a yard and half a dozen systems it does not control. The design question is not whether they fail — it is what the yard does while they are failing.
A live status feed is not published yet.
We are in pilot, and a status page with invented uptime figures on it is worse than no status page. Until there is a real feed, pilot tenants get incidents by email and phone, and hello@loadline.africa reaches a person.
Behaviour under failure, rail by rail
Weighbridge
Read over the indicator's own API. If the bridge is unreachable the gate falls back to a supervised manual reading, flagged on the trip and reconciled later — the yard never stops.
KRA eTIMS
Submissions are queued durably with retries and backoff. A KRA outage delays a control number; it never loses a document and never blocks a sale.
M-Pesa and banks
Inbound webhooks are signature-verified before the payload is touched, and replays are idempotent. A gateway outage delays reconciliation; the payment is matched when it arrives.
SMS, email and WhatsApp
Queued per message with delivery reported back. A gateway failure retries; nothing is dropped silently.
The rep and driver apps
Offline-first by design. Orders and deliveries are captured on the device and synced when signal returns — every mutation is idempotent, so a retry cannot double-post.
The rule underneath all of it
Every outbound mutation is idempotent and queue-backed with retry and backoff, and every inbound webhook is verified before it is parsed. A downstream outage must never block the yard or lose an order. That is a hard rule in the codebase, not an aspiration.
Reporting something
Write to hello@loadline.africa with the tenant, the trip or order number, and roughly when it happened. Every state change writes an append-only event with an actor and a timestamp, so a specific reference lets us reconstruct exactly what occurred.