> ## Documentation Index
> Fetch the complete documentation index at: https://developer.neurofit.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Diagnostics and support

> What to record in your own app so a reading problem can be understood, and what to send NEUROFIT support.

The SDK keeps its capture and signal-processing internals to itself: a reading returns the metrics and a quality
tier, and the events tell you what happened along the way. That is enough to understand almost every reading
problem, as long as your app keeps a short record of it.

The SDK sends nothing anywhere, so NEUROFIT cannot look a reading up. What you record is what support works from.

## What to record

Keep these with each reading attempt, in your own logs or analytics:

| What | Where it comes from |
| - | - |
| The reading id and completion time | `VitalsResult.id`, `VitalsResult.capturedAt` |
| The SDK version | `VitalsResult.sdkVersion` (or `VitalsSDK.version` before a result exists) |
| The quality tier | `VitalsResult.quality` |
| Platform, OS version and device model | Your own device info (on Android `Build.MODEL`, on iOS the machine identifier) |
| The guidance values that kept showing while positioning | `guidance` events |
| Every cancelled attempt and its reason | `cancelled` events (`contactLost`, `poorSignal`, `interrupted`, `cancelledByApp`) |
| The error, when a session failed | `failed` events and errors thrown by `start()` |
| How long positioning took before the reading started | The time from `start()` to `started` |

None of this contains health values beyond the result you already store, and none of it identifies the user.

## Useful slices

In the order they tend to pay off:

1. Withheld rate by device model. One model withheld across many users points at the device, not the users.
2. Cancel reasons by device model and by user. Frequent `poorSignal` for one user usually means a cold finger,
   too much pressure or a hand-held phone; for one model it can mean a thick case or weak optics.
3. How often positioning shows `frameDrop`, by device model. It usually tracks Low Power Mode or Battery Saver.
4. Positioning time. A long wait before `started` points at the fingertip placement, the guidance copy, or the
   lighting on a device without a torch.

## Contacting support

Write to [contact@neurofit.app](mailto:contact@neurofit.app) with:

* the SDK version, the platform and OS version, and the device model;
* the reading id and completion time, when the question is about a result;
* the events you recorded for the attempt: the guidance that kept showing, the cancel reasons, the error;
* what the user did, if you know it (seated or moving, phone on a table or in the hand, which finger).

[Troubleshooting](/troubleshooting) covers the common cases and is worth a look first.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.