Reliability
What we will commit to, and what we will not pretend
Khepee is pre-launch. Publishing a historical uptime figure for a platform with no production traffic would be meaningless, so this page describes the design and the commitments we are prepared to sign.
No production availability history yet
We have no live borrower traffic, and therefore no uptime record to report. Any vendor showing you a 99.99% figure for a product that has not launched is showing you an aspiration formatted as a statistic. Availability targets, measurement method, exclusions and remedies belong in the partnership agreement, where they are enforceable — and that is where we will put them.
Design
Built so that a deploy is not an outage
Most avoidable downtime in small platforms comes from deployment and configuration rather than from infrastructure failure.
- Graceful shutdown drains in-flight requests before exit
- Configuration validated at boot — a bad value stops the start rather than surfacing at the first request
- Stateless API processes, so capacity is a scaling decision rather than a rebuild
- Database indexes designed for the queries the product actually makes
Backup and recovery
A backup you have not restored is a hope
Recovery objectives will be agreed with each partner. The practice that matters is testing restores on a schedule rather than discovering the gap during an incident.
- Recovery point and recovery time objectives agreed per partnership
- Restores tested on a schedule, not assumed
- A verified snapshot is a precondition of any key rotation or migration
- Your data exportable in full at any time, so we are not a single point of failure
Incidents
What happens when something breaks
Detect
Structured logging and alerting on error rates, latency and audit-write failures.
Notify
Affected partners told promptly with what is known, rather than after the cause is understood.
Contain
Stop the harm first. Root cause analysis comes after service is restored.
Restore
Return to service, with the incident and every action recorded.
Report
A written post-incident report to affected partners, including what we got wrong.
Data incidents
A personal-data breach is a different procedure
An availability incident is inconvenient; a data incident is a regulatory event for your institution as well as ours. It follows a separate, faster path.
- Affected partner institutions notified without undue delay
- The audit trail establishes exactly what was accessed and by whom
- Your institution leads regulator and borrower communication — you hold that relationship
- The incident, the timeline and the remediation recorded in full
Dependencies
The parts we do not control
Honest reliability includes naming the dependencies whose failure becomes your outage regardless of what our code does.
- Your payment rails — a disbursement cannot complete if they are unavailable
- SMS delivery — one-time codes depend on a carrier route we do not own
- Your KYC provider, where an automated check is in the critical path
- Cloud infrastructure and connectivity
Degradation
Failing usefully rather than completely
When a dependency is down, the platform should keep doing everything that does not need it rather than presenting a blank error.
- A disbursement rail outage does not block origination or servicing
- Instructions queue with idempotency keys and reconcile when the rail returns
- Borrowers see the real state, including a delay, rather than a silent failure
- Officers can continue reviewing and deciding during a downstream outage
Coming soon
Negotiate the numbers with us
Availability targets, recovery objectives and remedies should be specific to your operation. Bring your requirements and we will tell you honestly what we can sign.