Developers
Logging and Monitoring an OTP Flow Without Storing the Codes
When verification breaks, users do not file a report. They leave. Good logging tells you about the break within minutes. Bad logging puts one-time codes and phone numbers into files that many people can read.
What to log
- Order created, number or email assigned, code received, code expired, order cancelled.
- Timestamps for each event so you can measure delay.
- A request ID that links the events of one flow.
- Provider name, country, service and the result.
What not to log
- The code itself.
- Full phone numbers. Keep the last two or three digits if you need to match.
- API keys, tokens and session cookies.
Metrics that matter
| Metric | Why it matters |
|---|---|
| Success rate by service and country | Shows which route is failing |
| Time to first code | A rising number is an early warning |
| Cancel and refund rate | Shows numbers that did not work |
| Wallet balance | Catches silent loss or abuse |
Alerts worth having
- Success rate drops below your normal level for a service.
- Time to first code doubles.
- A sudden spike in orders from one account or country.
- Wallet balance falls faster than normal.
Retention
Keep detailed logs for a short period and aggregated numbers for longer. Short retention reduces what you must protect and what you must disclose after an incident.
A sample log line
flow=abc123 event=code_received service=example country=PK delay_ms=18400 result=okReviewing the numbers weekly
- Compare success rate with last week.
- Find the slowest country and service.
- Check refunds and cancels for patterns.
- Remove any log field that nobody used.
Questions people ask
Can I log hashed codes?
It is rarely useful. Log the result of the check, not the code.
Do I need a monitoring product?
No. Counters in your own database and one alert script are enough to begin.
Related guides and pages
Create a free OtpGet account and try it with a small balance.