1
horus
298d

I want to build a "report-error" function into the app to make errors in production easier to track and debug. But i am unsure, what it should do actually.
Create a GitHub Issue? Then every Hoster needs a specific GitHub account and repo for that.
Send an Email? Then connectivity-related issues are not sendable. Send an Email with the frontend? Brr. Any Tips?

Comments
  • 1
    Lookup zoho bugtracker, or bugzilla maybe?

    I just googled "software bug reporting pipeline"

    Or the github route, but why not just make a report collecting account and use the API key and a template to make those reports.
  • 1
    Use a 3rd party service like honeybadger.io
  • 1
    Either what was previously suggested or log them into some temporary database while you wait to come up with an actual solution
  • 0
    Write to file, then try to send. If unable, signal to some service report or view that there are unreported issues.
  • 0
    I don't think automatic reports should be lumped with human-made issues in a bug tracker, some manual prefiltering and research is usually needed.
  • 0
    @lorentz Webapp, can't do file.
  • 0
    @horus how is the network optional then? Is it a PWA? Then you can dump it in localdb and automatically sync when the network comes back
  • 0
    @lorentz the network itself isn't optional i was not precise in this point. But the connection to server. It the Bugs reports target was an external service like GitHub the error reporting would at least not rely on a functioning backend.
  • 0
    @horus You can target a separate service you host, or an extremal event aggregator such as the ones mentioned in this thread. But the availability of the API used to get shit done doesn't have to be associated with the availability of error reporting just because they're owned by the same company. This is one of the natural roads to a microservice architecture; anything you can extract to another service can crash or survive independently from the main monolith.
  • 0
    Start off with a simple email link (mailTo) and see what kind of feedback you get.

    You'll probably mostly get feedback which is not proper bugs.

    And confusing reports like "the page doesn't work when I click" where you want to reply and ask for more details. The brilliant thing about email links compared to forms is that users will send you emails from their real adress so that you can actually reply.

    People also tend to write better feedback when sending it from their own email vs an anonymous form.
  • 0
    PS: don't be surprised if you get zero relevant bug reports, most users either don't look for bug report links or don't care about reporting bugs in general unless explicitly asked.

    I work for a website with a lot of users, we have a bug report feature on various contact pages but barely get anything from it, and when we do it's mostly opinions about content, rather than bug reports. (Good thing I guess, but even when we know we've introduced bugs - we almost never get any bug reports from users)

    Recently we added a new feature, and asked for feedback about about it, in the header of that page. Got tons of emails instantly (mostly design opinions but some decent bug reports too)
  • 0
    @jiraTicket I don't intend to build the kind of report feature you have in mind where you can post arbitrary text. I think of the oh-snap-the-app-crashed-do-you-want-report-the-incident-version. And the report contains stuff like browser/os information and so on.
  • 1
    @horus Oh! I see.

    I'd look into logging services like Sentry or similar.

    Not sure how easy it is to handle crash reports but I've seen that's a feature they often provide. And personally that's the kind of place I'd like to keep crash reports and other error reports.
  • 1
    @bioDan honeybadger seems fantastic. Whats been your experience?
  • 1
    @Wisecrack pretty good overall, i used it in my previous company on a SaaS product based on Ruby on Rails.

    It was automatically integrated with Jira so any ticket had the honeybadger link.

    We would send data to honeybadger on any backend or frontend error.

    In honeybadger we had all the information regarding the user who experienced the bug like user id, email, tomezone, url, etc. If it was a frontend error then we had frontend (js) configurations and state, console errors, screenshot, location, etc.If it was a backend error it was server logs, function, db query, server memory, call stack, etc.

    They have a decent documentation and were always responsive when we reached out for support (which rarely happened).
  • 1
    @bioDan it's fantastic to see a fairly new tool not be a giant pile of duct tape disguised as a working product.
Add Comment