# How to Set Up Custom Logging and Monitor App Events in Bubble

- Tool: Bubble
- Difficulty: Beginner
- Time required: 20-25 min
- Compatibility: All Bubble plans
- Last updated: March 2026

## TL;DR

Bubble's built-in server logs have limited retention, so building a custom logging system gives you full control over monitoring your app. This tutorial shows how to create a Log Data Type, record events from workflows, categorize logs by severity, filter and search logs in an admin dashboard, and set up alerts when errors occur so you catch issues before your users report them.

## Overview: Custom Logging in Bubble

This tutorial walks you through building a custom event logging system for your Bubble app. Bubble's built-in server logs retain data for only 6 hours on the Free plan, so a custom system gives you permanent records of important events, errors, and user actions that you can filter, search, and analyze.

## Before you start

- A Bubble app on any plan
- Basic understanding of Bubble Data Types and Workflows
- Familiarity with the Workflow tab and backend workflows
- An admin page or section in your app for viewing logs

## Step-by-step guide

### 1. Create the Log Data Type

Go to the Data tab and create a new Data Type called 'AppLog'. Add the following fields: 'event_type' (text — values like 'info', 'warning', 'error', 'debug'), 'message' (text — description of what happened), 'source' (text — which page or workflow generated the log), 'user' (User — the user who triggered the event, if applicable), 'details' (text — additional context or error messages), and 'severity' (number — 1 for debug, 2 for info, 3 for warning, 4 for error). The auto-generated Created Date field serves as your timestamp.

> Pro tip: Create an Option Set called 'LogLevel' with options Debug, Info, Warning, Error for cleaner filtering instead of free-text severity values.

**Expected result:** An AppLog Data Type exists with fields for event type, message, source, user, details, and severity.

### 2. Add logging actions to your workflows

In any workflow where you want to record an event, add a Create a new thing → AppLog action. Set the fields: event_type to the appropriate level, message to a description of the event, source to the page or workflow name, and user to Current User. For error logging, use the 'An unhandled error occurs' event. Create a workflow for this event and log Current workflow error's message and Current workflow error's code. For important user actions like signups, purchases, or data changes, add an AppLog creation step in the relevant workflow.

**Expected result:** App events and errors are automatically recorded as AppLog entries in your database.

### 3. Build the log viewer admin dashboard

Create a new admin page for viewing logs. Add filter controls: a Dropdown for event_type, a Date Range picker for time filtering, and a Search Input for text search. Below the filters, add a Repeating Group with type AppLog. Set the data source to Do a Search for AppLog with constraints matching your filter values. Display columns for timestamp (Created Date), event type, message, source, and user. Add color-coded badges for event types — red for error, yellow for warning, blue for info, gray for debug. Sort by Created Date descending so newest logs appear first.

**Expected result:** An admin dashboard displays logs in a filterable table with color-coded severity levels.

### 4. Set up automated error alerts

Create a backend workflow called 'check_error_alerts'. Use a database trigger event: When an AppLog is created and event_type is 'error'. Inside this trigger, add an action to send an email notification to your admin email address. Include the error message, source, timestamp, and user in the email body. You can also send a Slack notification via webhook using the API Connector if your team uses Slack for monitoring. For rate limiting, add a condition that only sends alerts if fewer than 5 error alerts have been sent in the last hour to avoid notification flooding.

> Pro tip: Use a separate 'AlertSent' Data Type to track when alerts were sent, preventing duplicate notifications for the same recurring error.

**Expected result:** When a critical error is logged, your team receives an email or Slack notification within seconds.

### 5. Implement log cleanup to manage database size

Logs accumulate quickly and can bloat your database. Create a scheduled backend workflow called 'cleanup_old_logs' that runs daily. Inside it, search for AppLog entries where Created Date is older than 30 days (or your preferred retention period) and event_type is not 'error'. Delete these records using a Schedule API Workflow on a List action to process them in batches. Keep error logs for 90 days or longer for debugging historical issues. You can also archive old logs by exporting them before deletion.

**Expected result:** Old non-critical logs are automatically cleaned up, keeping your database lean while preserving important error records.

## Complete code example

File: `Workflow summary`

```text
CUSTOM LOGGING SYSTEM SUMMARY
=====================================

DATA MODEL:
  AppLog Data Type:
    - event_type (text): info, warning, error, debug
    - message (text): event description
    - source (text): page/workflow name
    - user (User): who triggered it
    - details (text): additional context
    - severity (number): 1=debug, 2=info, 3=warning, 4=error
    - Created Date (auto): timestamp

  Optional: LogLevel Option Set
    Debug, Info, Warning, Error

LOGGING WORKFLOWS:
  User action logging:
    Workflow step → Create new AppLog
      event_type: 'info'
      message: 'User completed purchase'
      source: 'checkout_page'
      user: Current User

  Error logging:
    Event: An unhandled error occurs
    → Create new AppLog
      event_type: 'error'
      message: Current workflow error's message
      details: Current workflow error's code
      source: 'workflow_name'
      user: Current User

ADMIN DASHBOARD:
  Filters:
    Dropdown: event_type
    Date Range: Created Date
    Search Input: message contains
  Repeating Group: AppLog
    Sort: Created Date descending
    Columns: timestamp, type (color badge), message,
             source, user
  Color badges:
    error → red
    warning → yellow
    info → blue
    debug → gray

ALERTS:
  Database trigger: AppLog created + type = error
  → Send email to admin
  → Or: API Connector → Slack webhook
  Rate limit: max 5 alerts per hour

CLEANUP:
  Scheduled backend workflow: daily
  Delete AppLogs older than 30 days
    Except: event_type = error (keep 90 days)
  Process in batches via Schedule on a List
```

## Common mistakes

- **Logging too many events without considering WU costs** — Every Create a new AppLog action costs WUs, and logging every minor event can consume a significant portion of your WU allocation Fix: Log only meaningful events — errors, important user actions, and key workflow completions. Use debug-level logging only during development.
- **Not implementing log cleanup** — Logs accumulate rapidly and can grow your database to tens of thousands of records, slowing searches and increasing storage costs Fix: Schedule a daily backend workflow to delete logs older than your retention period
- **Placing log creation actions at the beginning of workflows** — If the log creation fails or slows down, it can block the actual business logic from executing Fix: Place log creation actions at the end of workflows or use Schedule API Workflow to log asynchronously

## Best practices

- Use consistent event type values across your entire app for easy filtering
- Include the source page or workflow name in every log entry
- Color-code log severity levels in your admin dashboard for quick scanning
- Set up email or Slack alerts for error-level events
- Implement log retention policies to prevent database bloat
- Log asynchronously using backend workflows to avoid blocking user-facing actions
- Keep error logs longer than informational logs for debugging purposes

## Frequently asked questions

### How long does Bubble keep its built-in server logs?

Bubble retains server logs for 6 hours on the Free plan. Paid plans have longer retention. A custom logging system gives you permanent records.

### Will custom logging slow down my app?

Each log entry is a database write (about 0.5 WU). For most apps, this is negligible. If you log many events, use backend workflows for asynchronous logging.

### Can I view logs from a specific user?

Yes. Add the User field to your AppLog Data Type and filter by user in your admin dashboard. This is useful for debugging user-reported issues.

### How do I log API call failures?

In the API Connector, enable 'Include errors in response.' In your workflow, check if the API response contains an error and create an AppLog with the error details.

### Should I log successful actions or just errors?

Log both, but at different severity levels. Use 'info' for important successes like purchases and signups, and 'error' for failures. Avoid logging routine actions that happen thousands of times daily.

### Can RapidDev help set up monitoring for my Bubble app?

Yes. RapidDev can build comprehensive logging and monitoring systems including error tracking, user activity logging, and automated alerting for your Bubble application.

---

Source: https://www.rapidevelopers.com/bubble-tutorial/setup-custom-logging-monitor-app-events-bubble
© RapidDev — https://www.rapidevelopers.com/bubble-tutorial/setup-custom-logging-monitor-app-events-bubble