Monitor Electron App Crashes and Send to Sentry

Hey there, Darian Vance here. Look, we’re all busy, and digging through raw text logs from our Electron apps is a time sink. I used to spend a couple of hours every week just manually grepping through crash dumps from user machines. It was tedious and inefficient. That’s when I decided to automate the whole process. By piping these crash reports directly into Sentry, I turned a manual chore into an automated, actionable alerting system. This setup not only saved me time but also helped our team catch and fix critical bugs before they impacted a wider audience. Let’s get this set up for you so you can reclaim some of that time, too.

Prerequisites

Before we start, make sure you have the following ready:

• A Sentry account and a project created for your Electron app.
• Your Sentry DSN (Data Source Name) from your project settings.
• Python 3 installed on the machine that will run the monitoring script.
• Access to the directory where your Electron app writes its crash logs.

The Step-by-Step Guide

Step 1: Prepare Your Environment and Configuration

First things first, you’ll need a couple of Python libraries. You can install them using pip. On your terminal, you would run a command like ‘pip install sentry-sdk python-dotenv’ to get the necessary packages. I’ll skip the standard virtual environment setup since I’m sure you have your own workflow for that. Let’s jump straight to the logic.

In your project directory, create a file named config.env. This is where we’ll safely store our Sentry DSN without hardcoding it into the script. It’s a much better practice for managing secrets.

# config.env
SENTRY_DSN="YOUR_SENTRY_DSN_GOES_HERE"
ELECTRON_LOG_PATH="path/to/your/electron_crash.log"

Pro Tip: In my production setups, I manage environment variables using a secrets manager like AWS Secrets Manager or HashiCorp Vault. For local development or a quick setup, a config.env file is perfectly fine, just remember to add it to your .gitignore file!

Step 2: The Python Script – The Heart of the Operation

Now, let’s create our Python script. I’ll call it monitor_crashes.py. The core idea is simple: the script will read the Electron log file, look for new crash entries since its last run, and send a formatted message to Sentry for each new crash it finds.

To avoid sending duplicate crash reports, we’ll keep track of the last line we read from the log file. We’ll store this position in a simple text file, which I’ll call last_pos.txt.

Here’s the full script. I’ll break down what each part does below.

import os
import re
import time
from dotenv import load_dotenv
import sentry_sdk

# --- Configuration ---
LAST_POS_FILE = 'last_pos.txt'
CRASH_HEADER_PATTERN = re.compile(r"\[\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}.\d{3}Z\] \[error\] Uncaught exception:")

def get_last_position():
    """Reads the last known file position."""
    if not os.path.exists(LAST_POS_FILE):
        return 0
    with open(LAST_POS_FILE, 'r') as f:
        try:
            return int(f.read().strip())
        except ValueError:
            return 0

def save_last_position(pos):
    """Saves the current file position."""
    with open(LAST_POS_FILE, 'w') as f:
        f.write(str(pos))

def process_log_file(log_path):
    """
    Reads the log file from the last known position,
    parses new crashes, and sends them to Sentry.
    """
    last_pos = get_last_position()

    try:
        with open(log_path, 'r') as f:
            f.seek(last_pos)
            
            current_crash_report = []
            in_crash_block = False

            for line in f:
                if CRASH_HEADER_PATTERN.search(line):
                    # If we find a new crash header and were already in a block, send the previous one
                    if in_crash_block and current_crash_report:
                        send_to_sentry(current_crash_report)
                    
                    # Start a new crash block
                    current_crash_report = [line.strip()]
                    in_crash_block = True
                elif in_crash_block:
                    # Append lines until we hit a blank line or another crash header
                    if line.strip() == "":
                        send_to_sentry(current_crash_report)
                        current_crash_report = []
                        in_crash_block = False
                    else:
                        current_crash_report.append(line.strip())

            # Send any remaining crash data at the end of the file
            if in_crash_block and current_crash_report:
                send_to_sentry(current_crash_report)

            # Update our position for the next run
            save_last_position(f.tell())
            print(f"Log processing complete. New position: {f.tell()}")

    except FileNotFoundError:
        print(f"Error: Log file not found at {log_path}")
    except Exception as e:
        # Send an error about the monitor script itself to Sentry
        sentry_sdk.capture_exception(e)
        print(f"An unexpected error occurred: {e}")


def send_to_sentry(crash_lines):
    """Formats and sends the crash report to Sentry."""
    if not crash_lines:
        return

    # The first line is our title
    message_title = crash_lines[0]
    # The rest is the body/stack trace
    crash_details = "\n".join(crash_lines)

    print(f"Sending crash to Sentry: {message_title}")

    with sentry_sdk.push_scope() as scope:
        scope.set_tag("source", "electron_log_monitor")
        scope.set_level("error")
        # Using set_extra to dump the raw log
        scope.set_extra("raw_crash_report", crash_details)
        sentry_sdk.capture_message(message_title)


if __name__ == "__main__":
    load_dotenv(dotenv_path='config.env')
    
    sentry_dsn = os.getenv('SENTRY_DSN')
    log_file_path = os.getenv('ELECTRON_LOG_PATH')

    if not sentry_dsn or not log_file_path:
        print("Error: SENTRY_DSN or ELECTRON_LOG_PATH not found in config.env. Aborting.")
        # In a real app, you might use 'return' here if this was in a function.
    else:
        sentry_sdk.init(
            dsn=sentry_dsn,
            traces_sample_rate=1.0,
        )
        process_log_file(log_file_path)

Step 3: Understanding the Script’s Logic

• Configuration: We load the Sentry DSN and log file path from our config.env file. This keeps sensitive information out of our code.
• Position Tracking: The get_last_position and save_last_position functions manage the last_pos.txt file. This ensures we only read new lines from the log file each time the script runs.
• Log Parsing: The process_log_file function opens the log, jumps to the last known position using f.seek(), and reads line by line. It uses a simple regular expression (CRASH_HEADER_PATTERN) to identify the start of a new crash report. It collects all lines belonging to that crash until it finds a blank line or the next crash header.
• Sending to Sentry: The send_to_sentry function takes the collected lines, formats them into a clear message, and uses sentry_sdk.capture_message. I personally like using set_extra to include the full, raw crash log. It’s incredibly useful for debugging.

Pro Tip: Customize the Sentry tags! I added a tag "source": "electron_log_monitor". You could also add the application version or environment (e.g., ‘production’, ‘staging’). This makes filtering and creating dashboards in Sentry much more powerful.

Step 4: Automating the Script

This script is designed to be run periodically. On a Linux-based server, a cron job is the perfect tool for this. You could set it to run every 5 or 10 minutes. Remember to run it from the directory containing your script and the config.env file.

Here’s an example of a cron entry to run the script every hour:

0 * * * * python3 monitor_crashes.py

If you’re on Windows, you can use the built-in Task Scheduler to achieve the same result.

Common Pitfalls (Where I Usually Mess Up)

• File Permissions: The most common issue I run into is the script not having permission to read the Electron log file or write the last_pos.txt file. Always double-check the permissions for the user running the cron job.
• Incorrect Log Path: A simple typo in the ELECTRON_LOG_PATH within your config.env file can leave you scratching your head. Verify it’s correct!
• Regex Mismatches: The provided regex pattern is a good starting point, but your Electron app’s crash logs might be formatted differently. You may need to adjust the CRASH_HEADER_PATTERN to match your specific log output. Test it against your actual log files.

Conclusion

And that’s it! You now have a robust, automated system for capturing Electron app crashes and getting them into Sentry where they belong. This isn’t just about saving time; it’s about shifting from a reactive “search for bugs” mindset to a proactive “get alerted to bugs” workflow. It allows your team to be more responsive and build a more stable application for your users. Happy coding!

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions