I like to keep debugging workflows as lightweight as possible — no heavy vendor contracts, no bloated dashboards I never open, and minimal noise in my inbox. Over the years I’ve found a sweet spot: a small session-replay layer that records the exact UI interactions needed to reproduce issues, coupled with instant Slack alerts that let the product and engineering teams triage bugs fast. Below I’ll walk through a practical, hands-on way to set this up with open-source components so you can start capturing meaningful sessions and routing them to Slack in under an hour.

Why a lightweight session replay + Slack alerts?

Full-featured commercial replay tools can be great, but they also tend to be heavy — large bundles, complicated privacy controls, and recurring costs. For small teams and solo founders, the priority is different: see what a user saw for the few sessions that matter, and surface them to your team without creating noise.

Here’s what I aim for in a lightweight workflow:

  • Minimal front-end footprint (low bundle size).
  • Open-source or self-hostable components where possible.
  • Simple backend storage for sessions (S3 or a managed object store).
  • Immediate Slack alerts with context and a replay link so PMs and engineers can triage quickly.

    • What I use and why

    Two open-source options I recommend:

  • rrweb — a mature, widely-used library for recording and replaying DOM events. Tiny by default and flexible.
  • OpenReplay — an open-source, full session replay platform with a UI and SDK. Slightly heavier, but offers a nice dashboard out of the box.

    • For my lean setup I typically choose rrweb for recording and combine it with a small server that stores events in an object store (S3-compatible) and publishes alerts to Slack. That keeps the frontend light and gives you full control of storage and retention.

    High-level architecture

    Here’s the flow I recommend:

  • Browser: rrweb records events and periodically uploads compressed blobs to a server.
  • Backend: Receives uploads, saves blobs to S3 (or DigitalOcean Spaces, etc.), creates an index entry in a lightweight DB (Postgres/SQLite), and runs a simple rule engine to decide whether to alert Slack.
  • Slack: An alert message containing user context, breadcrumbs, and a link to replay the session (hosted on your server or a simple static player).

    • Step-by-step setup (rrweb + S3 + Slack)

    Below is a concise plan you can implement incrementally.

    1) Add rrweb to your app

    Install rrweb via npm or yarn. On the client:

  • Initialize rrweb recording when the user session starts.
  • Batch events and upload them to your backend endpoint every X seconds or when the batch reaches a certain size.

    • Key tips:

  • Record only authenticated or important paths by gating rrweb with a feature flag or a query parameter — you don't need to record every anonymous visitor.
  • Mask sensitive inputs (passwords, credit card fields). rrweb supports input masking via event transformations.

    • 2) Backend uploader

    Make a small endpoint (/upload-session) that accepts an events payload, compresses it (gzip), and pushes to an S3 bucket with a predictable key like sessions/{sessionId}/{timestamp}.json.gz. Store a lightweight index record in your DB that contains:

    FieldPurpose
    session_idUnique id for the session
    user_id / anon_idWho this session belongs to
    urlInitial URL
    events_blob_keyS3 key to the compressed events
    created_atTimestamp
    alertedWhether we already sent a Slack alert

    The logic is intentionally small: upload, record metadata, return 200. Keep the endpoint idempotent so retrying uploads is safe.

    3) Simple rule engine for alerts

    Alerts should be rare and signal-worthy. I usually trigger Slack notifications on one of these conditions:

  • Console errors (the browser reports an unhandled Error or window.onerror triggers).
  • High rage-clicks / repeated clicks on the same element (a strong signal of a broken UI).
  • Failed network requests to critical endpoints (500s on /api/checkout, for example).

    • To implement this, collect lightweight telemetry alongside rrweb events — browser console errors, network errors (capture via fetch/XHR wrapper), and a small click counter. Send a summary to the server; if any rule matches, mark the DB record for alerting.

    4) Send Slack alerts with context

    When a session meets your alert criteria, send a Slack message with:

  • User context: user id, email (if available), device & browser.
  • Error summary: console error message, stack (if present).
  • Quick actions: link to replay, link to user profile, or a “snooze” button.

    • Use Slack Incoming Webhooks or the Slack API to format a message. Keep the message compact but actionable. Example payload highlights:

  • Title: "UI Error — Uncaught TypeError on /checkout"
  • Fields: user id, timestamp, browser, OS
  • Buttons: "Open Replay", "Assign", "Ignore"

    • 5) Replaying the session

    To replay the compressed rrweb events, you can either:

  • Host a simple static page that fetches the events blob from S3, decompresses it in the browser, and plays it with rrweb-player.
  • Build a small server-side preview endpoint that streams the decompressed events into a simple player.

    • rrweb-player is a tiny library that provides an out-of-the-box UI for replays. You can wrap it in your own minimal UI that includes the Slack linkback and metadata.

    Privacy and data minimization

    Be intentional about what you record:

  • Mask or exclude inputs that may contain PII.
  • Only enable replay for authenticated users or specific environments (staging, beta).
  • Set retention policies for S3 objects — e.g., delete after 30 days unless flagged for investigation.

    • Open-source libraries give you control here — you’re responsible for what you capture, which is an advantage if you want strict privacy guarantees.

    Tool comparison (quick)

    ToolProsCons
    rrwebTiny, flexible, well-documentedRequires custom infra to host replays
    OpenReplayFull replay platform, has UIHeavier to self-host
    Commercial tools (FullStory, LogRocket)Feature-rich, supportCostly, larger bundle sizes

    Operational tips

    From experience, the small operational details matter more than the tech choice:

  • Start with alert thresholds that are strict — too many alerts will kill the system’s usefulness.
  • Tag sessions with feature flags or release versions so you can correlate bugs to deployments.
  • Include a simple “why” field in Slack alerts where a PM or QA can add quick reproduction notes.
  • Rotate the responsibility for checking alerts among team members so they don’t pile up.

    • Setting this up has helped me triage UI bugs much faster: instead of a long Slack thread, I can open the replay, see what the user clicked, which network request failed, and who should own the fix. It’s not about capturing every interaction — it’s about capturing the right ones, keeping the setup light, and delivering context to the team where they already work: Slack.