Status
Users need to know whether login, top-up, route generation, suppliers, probes, and settlement are healthy.
What the public page should cover
- Login and OTP/Telegram authentication.
- Rial top-up instructions and cardholder confirmation.
- Auto-route selection and subscription generation.
- Supplier verification, reachability probes, and settlement.
- Withdrawals, support inbox, and transparency publication.
Current public proof
Today the status page can check public gateway health, readiness, bootstrap, and transparency endpoints from the browser. That is useful launch evidence, but it is not a full incident status system with history, ownership, and next-update times.
How incidents should be handled
Incidents should have a timestamp, affected users, affected regions or protocols, mitigation, and next update time. Payment or security incidents should include a support path.
Report a visible incident
Copy a safe public incident update
Use this packet when Torna needs a public status update during an outage, payment delay, degraded route, supplier incident, or security-adjacent event. It keeps the update useful without exposing customer data or operational secrets.
- Severity
- monitoring / degraded / partial outage / major outage / security review
- Start time and timezone
- YYYY-MM-DD HH:mm, timezone
- Affected surface
- login / top-up / connect / iPhone import / supplier probes / withdrawal / security
- Affected region, ISP, client, or protocol
- country, ISP, app, protocol, or 'unknown - investigating'
- User impact
- what users see and whether existing sessions still work
- Mitigation or workaround
- current action, fallback route/client, support path, or 'none yet'
- Owner and next update
- operator initials/contact path; next update time
- Evidence reference
- status ticket, probe id, or public incident id only
Keep public updates safe
Do not include secrets, tokens, private keys, customer personal data, full logs, payment receipts, exploit payloads, root/provider account details, or raw signed subscription URLs. Publish safe references only and move sensitive detail to support, abuse, or security channels.
Live public checks
These checks run from your browser against public gateway endpoints. They are useful launch evidence, but they are not a replacement for a staffed incident page with history and next-update times.
The HTTP process can answer liveness traffic.
/healthThe gateway says it can serve real traffic.
/readyzClients can fetch signed failover endpoints.
/v1/bootstrap/endpoints.jsonTransparency artifacts can be verified offline.
/v1/.well-known/torna-pubkey.jsonPublic mirror list is signed and fetchable.
/v1/transparency/manifestReserve/liability snapshot is signed and fetchable.
/v1/transparency/reservesCurrent incident notice
Torna is still pre-launch. Operators must update this block during a real incident with the affected region, protocol/client, mitigation, owner, and next-update time.
- Affected surfaces
- Login, top-up, route generation, public pool, supplier settlement
- Incident owner
- Launch operator on duty, to be named before advertising
- Next update
- Within 30 minutes during an active paid-service incident
- Support path
- support@torna.io for users; abuse@torna.io for supplier/provider abuse
What operators must publish
Every active incident update should include severity, start time, affected users or regions, affected protocol/client, mitigation, workaround, owner initials, and the next update time.
Incident history
Report a status issueNo public production incidents recorded yet
Pre-launchThis is expected before advertising. The first launch drill should create a real status update entry, even if the incident is simulated.