The best beta feedback describes what happened, when it happened, and the device conditions around it. It does not need to be technical.
The most useful details
A short report becomes much easier to investigate when it includes a few consistent facts.
- JourneyStarting station, destination, selected route, and approximate travel time.
- Alert resultEarly, late, on time, duplicated, or not received, and by roughly how many stations.
- PhoneDevice model, operating-system version, and relevant battery restrictions if known.
- ConditionsWhether the screen was locked, the app was in the background, or the phone restarted.
Battery feedback needs context too
If battery use seemed high, note the approximate percentage before and after, journey length, and whether the screen stayed on.
That context helps separate active-screen use, weak-signal conditions, and background location behaviour.
Honest criticism is the point of a beta
A failure report is not discouraging when it is specific. It is evidence that can reveal a repeatable pattern and guide the next test.
The beta is not asking users to confirm that the idea is good. It is asking whether MetroPing is useful and reliable during an actual commute.
Was the alert early, late, on time, or missing?
Add the journey and device details, and a frustrating experience becomes useful evidence.
Try it on a real Delhi Metro journey.
MetroPing is not affiliated with DMRC. Use it as an additional reminder and share honest feedback about the experience.
Try MetroPing