RuntimeError.js

Why waste your time at yet-another-middleman-website to manage your errors. Deploy your own, free runtimeerror.js & upgrade your Github Issues to manage error tracking directly.

Clustered errors, full context & stacktrace in your email notifications, wontfix, direct email replies to @johnappleseed works as intended. What's not to like?

NOTE: integrations to trello, pivotal tracker or any other things should be added as a provider

How a human manage errors

1. Use a generic error message to group errors, e.g. Session#create: User id={N} not found
2. Create a new issue if the generic title is new (team will be notified via Github)
3. Update occurrence count if issue already exist (no notifications, keep issue fresh)
4. Reopen issue if it was closed, and add fresh debug data in comments (notify team of regression)
5. Ignore if issue was labelled wontfix (no notifications)

runtimeerror.js does exactly this.

1. Setup github account for api purpose

The way github works is that the creator/commenter of an issue will not be notified. This is a correct logic, but does not suit our purpose.

We recommend using a separate bot github account instead of your own so that when errors happen, bot will create the issues and you'll get the github notifications.

1. Create a separate github account, e.g. bot
2. Add bot to the repository you want to integrate with.
3. Go into Github.com > Account > Applications > Personal Access Tokens and create a token for bot account, e.g. token
4. Optionally, turn off all email and web notifications for bot account

2. Deploy to a server

The easiest option is to deploy on Heroku

1. Create a heroku app
2. git push this repository to your heroku app
3. Optionally, set your environment variables (aka heroku config:add)

SECRET=<your token>
REPO=<your org>/<your repo> # e.g. rails/rails
PROVIDER=github # (optional, currently only supports github)
LABEL=bug # (optional)

This setup uses the web.js mechanism.

Setting environment variables is optional because you can also use per-request config (see next point).

Per-Request config via email address

runtimeerror.js parses the email address format to extract REPO, SECRET, PROVIDER in the format of "{repo}" <{secret}@{provider}.com>

For example:

"rails/rails" <aaabbccddeeff@github.com>

would configure the error to be posted to

REPO=rails/rails
SECRET=aaabbccddeeff
PROVIDER=github

This allows for multiple repo/secret/provider accounts to share the same instance of runtimeerror.js deployed

Mechanisms

web.js

Upload an email as a bug report on Github Issues (email subject + email body). In production environment, we recommend setting environment variable HIDE_UPLOAD_FORM=1 to hide this form.

node web.js

The web application is compatible with these popular error reporting tools

• bugsnag
• rollbar
• runtimeerror_notifier gem (set the email to as described in config via email address section above)

procmail.js

Pipe email file through stdin. Compatible as Postfix mailbox_command config or as procmail replacement.

node procmail.js < sample.eml

NOTE: email to is used as account config, see config via email address section above

cli.js

Command line arguments

node cli.js "title of bug" "bug description body"

Changelog

• 0.2.0 Issue description now shows sparkline image, reflecting error trend of past 7 days

LICENSE

GPL v2

---

Brought to you by RuntimeError.net