Downtime Procedures
How we detect, tell customers, and bring AgileFlex / FANMS back when production is down or under planned maintenance.
1. What this covers
Production admin (fantech.fuelingagilenigeria.com) and company (fleetos.fuelingagilenigeria.com) apps, API, reverse proxy, and the database we operate. Customer ISP problems and third-party bank/telematics outages are outside our full control; we still communicate impact when our service is affected.
2. Severity
| Level | Example | Restore start |
|---|---|---|
| Critical | Site down for everyone; data at risk | Immediately (best effort) |
| Major | Login / balances / uploads broken for many users | Within 4 hours (business time) |
| Minor | Slow or non-critical feature | Next business day |
| Planned | Scheduled maintenance | Announced ahead when practical |
3. Unplanned downtime — steps
- Confirm — check HTTPS sites and container status
- Contain — roll back a bad release, or fix proxy/host first
- Protect data — no rushed destructive DB work; use backups
- Communicate — what is down, what still works, next update time
- Recover — restore service; smoke-test login and a core screen
- Close — short cause/fix note; use Incident Response Policy if security-related
4. How we recover
- Bad deploy: redeploy the previous known-good container image
- Crash: Docker auto-restarts containers; investigate logs if crash-looping
- Database: daily off-server DB dumps; restore after verification
- TLS / edge: repair or reload Caddy on the VPS
5. Planned maintenance
Prefer off-peak windows, announce when service may pause, deploy test then production, keep the prior image for rollback, then verify both HTTPS portals.
6. Limits (honest)
We run production on a single VPS with Docker and off-server database backups. This is a real downtime playbook — not a multi-datacentre guarantee or paid SLA unless written in a customer contract.