Firebase Crashlytics Not Showing Crashes in Flutter? 7 Causes and Fixes (2026)

By giosaia (GSPTeck) · Published 2026-11-14 · Last verified 2026-11-14

Why is Firebase Crashlytics not showing crashes from my Flutter app?

Usually because no report has been sent yet, the report was sent but is hidden by the dashboard's default filter, or collection is switched off for the build you're testing. Firebase's own test guide says to force a test exception, relaunch the app and wait: if the crash still isn't in the dashboard after five minutes, turn on debug logging to see whether the app is sending reports at all. This guide turns that advice into seven checks in the order we run them, checked against the Firebase Crashlytics Flutter documentation (last updated 2026-11-12) on 2026-11-14.

GSPTeck is giosaia's indie studio building mobile and web apps with Flutter and Firebase, and this is the order we'd check things in before blaming the SDK. They assume you already followed the Crashlytics get-started guide for Flutter.

The 7 causes at a glance

Each cause has a quick tell, so you can usually rule it in or out in a minute or two.

1. Did the app restart after the error?

Non-fatal errors only upload on the next launch or with the next fatal report. Firebase's customization guide says that in Flutter apps "fatal reports are sent to Crashlytics in real-time without the need for the user to restart the application", while non-fatal reports "are written to disk to be sent along with the next fatal report or when the app restarts."

So if you throw a test exception that your handler records as non-fatal and then keep the app open, nothing reaches the console yet. Close the app fully, open it again, then give it the five minutes Firebase's guide to testing your Crashlytics implementation mentions before you refresh the dashboard.

2. Is the dashboard filter hiding non-fatal errors?

Check the event type filter before anything else. A widely upvoted Stack Overflow answer points out that the Crashlytics page can open filtered to crashes only, and that Flutter exceptions recorded through recordFlutterError are non-fatal, because the Android activity keeps running. Clear the filter so fatal and non-fatal events both show.

If you want uncaught framework errors counted as crashes, use FirebaseCrashlytics.instance.recordFlutterFatalError for FlutterError.onError, as the get-started guide does, or pass fatal: true to recordError.

3. Is collection switched off in debug builds?

Often, and on purpose. The official FlutterFire Crashlytics example app only enables collection in non-debug builds (const enabled = !kDebugMode;) unless a testing flag is set. If you copied that pattern, your debug runs will never report.

Opt-in reporting has the same effect. Firebase's guide to customizing crash reports shows how to turn off automatic collection with firebase_crashlytics_collection_enabled set to false in AndroidManifest.xml (or FirebaseCrashlyticsCollectionEnabled in Info.plist), then turn it back on with setCrashlyticsCollectionEnabled(true). That override persists across later launches, and while collection is off, crash information is stored locally on the device instead of being sent.

For a quick test, call await FirebaseCrashlytics.instance.setCrashlyticsCollectionEnabled(true); after Firebase.initializeApp(), or test a release build. If the app behaves differently in release, our guide to Flutter apps that work in debug but not in release covers the other usual suspects.

4. Are all three error handlers in place?

Each one catches a different kind of error, and a missing one means a whole class of errors never reaches Crashlytics:

• FlutterError.onError catches errors thrown inside the Flutter framework, such as build and layout errors.
• PlatformDispatcher.instance.onError catches asynchronous errors the framework doesn't handle; Firebase's example records them with recordError(error, stack, fatal: true) and returns true.
• Errors outside the Flutter context need an error listener on the current isolate, Isolate.current.addErrorListener(...), per the customization guide.

Make sure WidgetsFlutterBinding.ensureInitialized() and await Firebase.initializeApp() run before you assign the handlers, as in the get-started sample.

5. Is your own code catching the error first?

A caught exception is invisible to Crashlytics unless you record it. Wrap risky calls the way the guide shows: catch (e, s) { await FirebaseCrashlytics.instance.recordError(e, s, reason: 'a non-fatal error'); }. Those then appear as non-fatal issues.

Watch the limit, too. Firebase notes that Crashlytics "only stores the most recent eight recorded non-fatal exceptions"; if your app throws more than eight before the next upload, the older ones are lost. Logging every caught error in a loop can push out the one you're looking for.

6. Is the build using a stale Firebase config?

Rerun the setup commands and rebuild. The get-started guide says running flutterfire configure keeps the Firebase configuration up to date and, for Android, adds the required Crashlytics Gradle plugin. Then rebuild with flutter run; several developers in a Stack Overflow thread on Crashlytics not reporting anything in Flutter fixed it with flutter clean before rebuilding.

Also confirm the app ID in the Firebase console matches your package name and build flavor. Reports from a debug flavor with a different application ID go to that app's dashboard, not your production one.

7. Do crashes arrive but with unreadable stack traces?

Then it's symbols, not reporting. If you build with --split-debug-info or --obfuscate, Firebase says Android projects must upload Flutter debug symbols with Firebase CLI v11.9.0 or later, using firebase crashlytics:symbols:upload --app=FIREBASE_APP_ID PATH/TO/symbols, before reporting a crash from that build. Apple platforms upload automatically with Flutter 3.12.0+ and plugin 3.3.4+. Our walkthrough of Flutter obfuscation and Crashlytics symbol uploads has the full steps.

How do I confirm the app is sending reports?

Turn on Crashlytics debug logging and look for the upload line. On Android, Firebase's test guide gives two commands: adb shell setprop log.tag.FirebaseCrashlytics DEBUG, then adb logcat -s FirebaseCrashlytics. Force a test crash and look for Crashlytics report upload complete or code 204. On Apple platforms, add -FIRDebugEnabled to the scheme's launch arguments and look for Completed report submission.

If the log shows a successful upload but the dashboard stays empty after five minutes, the problem is on the console side (checks 2 and 6). If there's no upload line, it's on the app side (checks 1, 3, 4 and 5). Firebase says to contact Firebase Support with your log output if neither helps.

Once reports flow, a fixed review routine keeps them useful; see our weekly Crashlytics triage cadence for solo developers, and add a forced test crash to your Flutter and Firebase release checklist for Google Play. You can see the Flutter apps we ship this way on the GSPTeck homepage.

FAQ

How long does Crashlytics take to show a crash?

Firebase's test guide says to refresh the dashboard and enable debug logging if a test crash still isn't showing after five minutes. Non-fatal errors only upload when the app restarts or with the next fatal report.

Does Crashlytics work in Flutter debug mode?

Yes, if collection is enabled. Many apps copy the FlutterFire example, which disables collection when kDebugMode is true, so debug runs don't report until you enable collection explicitly.

Why are my Flutter errors showing as non-fatal?

Errors recorded with recordFlutterError, or recordError without fatal set to true, are non-fatal. Use recordFlutterFatalError or fatal: true if you want them counted as crashes.

Does FirebaseCrashlytics.instance.crash() work for testing?

It forces a native crash, which is a valid test. Firebase's current guide uses a button that throws an exception, which also tests your Flutter error handlers.

Sources

• Firebase: Test your Crashlytics implementation (Flutter) (last updated 2026-11-12, checked 2026-11-14)
• Firebase: Get started with Crashlytics for Flutter (last updated 2026-11-12, checked 2026-11-14)
• Firebase: Customize your Crashlytics crash reports (Flutter) (last updated 2026-11-12, checked 2026-11-14)
• Stack Overflow: Crashlytics crashes not reported to the console in Flutter (community answers, checked 2026-11-14)