Debugging undefined properties in React Native with Sentry Logs
Use Sentry Logs to determine whether an undefined property is a first-render timing issue in your React Native app or actually missing from your backend API response.
Before you start
SDKs & packages
- @sentry/react-native installed in your mobile app
- @sentry/node (or equivalent) installed in your backend
- Logging enabled in both SDKs
Accounts & access
- Sentry account with a React Native project
- Backend project in the same Sentry organization
- Access to deploy code to both frontend and backend
Knowledge
- Basic familiarity with React Native development
- Understanding of REST APIs and async data fetching
1 Make sure logs are flowing into Sentry
This walkthrough assumes a React Native mobile app, a backend API, and Sentry SDKs already installed for both. Make sure you are logging the API response payload on the backend and the relevant data on the frontend right before you access the property that is throwing the error. You can verify logs are flowing by checking your Logs Explorer.
React Native log setupimport * as Sentry from "@sentry/react-native";
Sentry.init({
dsn: "https://examplePublicKey@o0.ingest.sentry.io/0",
enableLogs: true,
});
// Log user data before accessing properties
Sentry.logger.info("User profile loaded", {
userId: user.id,
hasProfile: !!user.profile
});
2 Open the issue and inspect the stack trace
In Sentry, go to Issues for your React Native project and open the issue containing the Cannot read property of undefined error. In the Event view, scroll to the Stack Trace and identify the exact line where you access the undefined property. From the stack trace alone, you cannot tell if the property is only undefined during first render or truly missing from your backend.
3 Scroll to the Logs section and expand the feed
Stay on the same Issue and Event page. Scroll down until you see the Logs section and click View more. This opens the full log stream captured during the same session as the crash. Because Sentry connects logs to issues, traces, and Session Replay, you get a single timeline that includes logs from both your React Native app and your backend. You can also explore all logs in the Logs Explorer.
Sentry Logs Explorer
4 Find the API logs from the backend
In the expanded logs view, scan the feed for your API endpoint. Locate the log line where you printed the response values returned from the backend. Confirm this log entry is tagged as coming from the backend service. You should now see exactly what your backend sent in the same request that led to the crash. Use the Logs Explorer to filter by service or endpoint.
Structured logging in Sentry 5 Compare frontend vs backend logs to identify the issue
Use the combined logs in the Logs Explorer to decide:
- Scenario 1 (Timing issue) — Backend logs show the property as valid, but frontend logs show it undefined on first render before data arrives.
- Scenario 2 (Data issue) — Backend log shows the property as undefined or missing, and frontend log confirms the same. This means your backend is returning invalid data, not a timing issue.
6 Fix the data contract and redeploy
Once logs confirm the property is truly undefined from the backend: Update your API handler to always return a safe default value instead of undefined. Optionally adjust your types or validation so the property cannot be undefined. Add or update backend logs to clearly show the final values returned on each request.
Structured log dataapp.get("/api/profile", async (req, res) => {
const profile = await getUserProfile(req.user.id);
// Ensure safe defaults for all properties
const safeProfile = {
...profile,
settings: profile.settings ?? {},
preferences: profile.preferences ?? "default",
};
Sentry.logger.info("Profile API response", {
userId: req.user.id,
profile: JSON.stringify(safeProfile)
});
res.json(safeProfile);
});
7 Re-run the flow and verify with logs, traces, and replay
Redeploy your backend and repeat the same user flow that previously crashed. In Sentry, confirm the original issue stops reproducing in Issues. Check the Logs Explorer to verify the API response now shows valid values. Jump to the Trace Explorer to see which spans were active, or watch a Session Replay to see exactly what the user did before and after the fix.
Sentry logs overview
That's it.
You know where the bug is.
Logs from both your app and backend confirmed whether the property was missing from the API response or just undefined during the first render. No more guessing.
- Connected frontend crashes to backend API responses
- Distinguished timing issues from data issues
- Used distributed tracing to correlate logs across services
- Verified fixes with Session Replay and traces
Pro tips
- 💡 Add structured attributes to your logs (like userId, endpoint, requestId) to make filtering and correlation easier in the Logs Explorer.
- 💡 Use different log levels strategically: info for successful operations, warn for recoverable issues, error for failures.
- 💡 Include timestamps in your log context to help identify race conditions and timing issues.
- 💡 Set up log-based alerts to catch issues before they become widespread crashes.
Common pitfalls
- ⚠️ Don't log sensitive data like passwords, tokens, or PII—use Sentry's data scrubbing or redact before logging.
- ⚠️ Avoid excessive logging in production—it can impact performance and increase costs. Use sampling for high-volume endpoints.
- ⚠️ Remember that logs are eventually consistent—there may be a short delay before they appear in Sentry.
- ⚠️ Don't assume the order of logs across services reflects actual execution order without checking timestamps.
Frequently asked questions
@sentry/react-native for your mobile app and @sentry/node for your backend). However, Sentry automatically correlates logs across services using distributed tracing.What's next?
Fix it, don't observe it.
Get started with the only application monitoring platform that empowers developers to fix application problems without compromising on velocity.