Firebase Analytics limits projects to 500 unique event types. When you exceed this limit, Analytics returns Code 8 and stops logging additional event types. Unlike other errors, this limit is permanent per project and cannot be reset without creating a new Firebase project.
This error occurs when your Firebase Analytics implementation has already logged more than 500 distinct event type names (event names) within a single project. Firebase Analytics enforces this limit as a quota restriction to maintain performance and database efficiency across all projects. Event types in Firebase Analytics are the unique names you give to tracked actions in your application—things like "page_view", "button_click", "user_signup", or "checkout_completed". While there is no limit on the total volume of events you log (you can log millions of events), they must fall within 500 or fewer distinct event name categories. When you exceed the 500 event type limit, Firebase Analytics logs error code 8 and refuses to process any additional new event type names. Existing event types continue to work normally, but any code that attempts to log a new event type name for the first time will be silently dropped. The error appears in your console but doesn't throw an exception, making it easy to miss until you review your analytics data. Critically, unlike user property or parameter limits, the 500 event type limit is permanent per Firebase project. You cannot reset it within the same project—the only way to start fresh is to create an entirely new Firebase project.
First, see how close you are to the 500-event-type limit. Open Firebase Console and navigate to Analytics > Events to see all registered event types and their volumes.
Look for:
- Total count of event types listed
- Events with very low volume (likely obsolete or debug events)
- Event names with minor variations (like "purchase" vs "Purchase" vs "PURCHASE")
Screenshot or document this list for analysis in the next steps.
Also check your Firestore console or BigQuery (if linked) to spot-check your actual event diversity.
Review the event types in your Firebase Console and identify candidates for removal:
- Events with zero or near-zero volume: Old test events, deprecated tracking, or experiments that ended
- Events from previous app versions: Features that were removed but event logging remains
- Debug events: Events with names like "test_event", "debug_purchase", or "temp_tracking"
- Duplicate names: Events that serve the same purpose but with slightly different names
Document which events you plan to stop logging, then remove the corresponding logEvent() calls from your codebase:
// REMOVE these deprecated event logs:
// firebase.analytics().logEvent('old_feature_click', {...});
// firebase.analytics().logEvent('test_purchase', {...});
// firebase.analytics().logEvent('deprecated_user_action', {...});Even if you stop logging to these event types in your new code, old app versions may continue to send them. The existing event type names will remain in your Firebase project and count toward the 500 limit, but you'll prevent new ones from being added.
Establish a strict naming convention for new events and consolidate similar events:
// BEFORE: Too many distinct event names
firebase.analytics().logEvent('button_clicked');
firebase.analytics().logEvent('link_clicked');
firebase.analytics().logEvent('menu_opened');
firebase.analytics().logEvent('menu_closed');
firebase.analytics().logEvent('form_submitted');
firebase.analytics().logEvent('form_validation_error');
// AFTER: Fewer event types using parameters
firebase.analytics().logEvent('interaction', {
interaction_type: 'button_click',
element_id: 'submit_btn'
});
firebase.analytics().logEvent('interaction', {
interaction_type: 'link_click',
element_url: '/pricing'
});
firebase.analytics().logEvent('menu_state_change', {
action: 'opened' // or 'closed'
});
firebase.analytics().logEvent('form_event', {
form_name: 'signup',
event_type: 'submitted' // or 'validation_error'
});This approach:
- Reduces event type count by ~50%+
- Uses event parameters (max 25 per event, up to 500 distinct parameter names) for variation
- Makes analytics queries more consistent
- Improves data cohesion in reports
Firebase provides a set of recommended event names that work across all app types. Using these standardized events reduces your custom event count and unlocks automatic features:
// Recommended events for most apps
firebase.analytics().logEvent('page_view', {
page_title: 'Product Details',
page_path: '/products/123'
});
firebase.analytics().logEvent('view_item', {
items: [{ item_id: '123', item_name: 'Product' }]
});
firebase.analytics().logEvent('add_to_cart', {
items: [{ item_id: '456', item_name: 'Widget' }]
});
firebase.analytics().logEvent('purchase', {
transaction_id: 'tx_999',
value: 99.99,
currency: 'USD'
});
firebase.analytics().logEvent('sign_up', {
method: 'google' // or 'email', 'apple', etc
});
firebase.analytics().logEvent('login', {
method: 'email'
});Replace your custom event names with these whenever possible. See the official Firebase documentation for the complete list of recommended events for your app type (ecommerce, gaming, travel, etc.).
Enable Firebase debug mode and verify that your event consolidation is working correctly:
// Web SDK
firebase.analytics().setAnalyticsCollectionEnabled(true);
// Android (via adb)
adb shell setprop debug.firebase.analytics.app <your-package-name>
// iOS (via Xcode scheme arguments)
-FIRDebugEnabledSteps:
1. Enable debug mode in your app
2. Trigger events from your app (clicks, page views, form submissions)
3. Open Firebase Console > Analytics > DebugView
4. Verify that:
- You see events appearing in real-time
- No error code 8 warnings appear
- Event names match your consolidation scheme
- Event parameters contain the expected data
5. Disable debug mode before deploying to production
The No-Reset Problem: Unlike the 25 user property or 25 event parameter limits (which reset when you delete properties), the 500 event type limit is permanent within a Firebase project. Once you log an event type name, it is forever associated with your project's quota, even if you never log to it again. The only way to reset to 0/500 is to create a completely new Firebase project.
Case Sensitivity Gotcha: Event names are case-sensitive. "Purchase", "purchase", and "PURCHASE" count as three separate event types. Always establish a strict lowercase-with-underscores (snake_case) naming convention: "page_view", "add_to_cart", "form_submit".
Multi-Version Challenge: If you have users on multiple app versions in production, older versions may continue logging event types you've deprecated in newer versions. Plan your deprecation carefully and communicate timelines to mobile users (who may not update for weeks).
BigQuery and GA360 Considerations: If your Firebase project is linked to BigQuery, the 500 event type limit still applies—BigQuery cannot override Firebase's hard limits. Google Analytics 360 does not provide relief for this limit either; it applies to Firebase Analytics itself, not the GA integration layer.
Event Type Recovery: If you genuinely need to exceed 500 event types and have already consumed most of your quota, your only option is to create a new Firebase project and migrate your app's tracking configuration to point to the new project. Plan this migration carefully in a feature branch before going to production, as switching projects mid-stream can create data gaps.
Recommended Strategy: Design your event taxonomy upfront before launch. Use a spreadsheet or tracking plan document listing all event types and their parameters. Aim for a lean set of core events (30-50) using event parameters for variation, and review the plan with your team before implementation to avoid waste.
Callable Functions: INTERNAL - Unhandled exception
How to fix "Callable Functions: INTERNAL - Unhandled exception" in Firebase
auth/invalid-hash-algorithm: Hash algorithm doesn't match supported options
How to fix "auth/invalid-hash-algorithm: Hash algorithm doesn't match supported options" in Firebase
Hosting: CORS configuration not set up properly
How to fix CORS configuration in Firebase Hosting
auth/reserved-claims: Custom claims use reserved OIDC claim names
How to fix "reserved claims" error when setting custom claims in Firebase
Callable Functions: UNAUTHENTICATED - Invalid credentials
How to fix "UNAUTHENTICATED - Invalid credentials" in Firebase Callable Functions