Failbot JS

A Failbotg client for JavaScript.

Installation

This package is published to npm as @github/failbot.

❯ npm install @github/failbot

Usage:

const {Failbot, HTTPBackend, LogBackend} = require('@github/failbot')

const failbot = new Failbot({
  app: 'my-cool-app',
  backends: [new HTTPBackend({haystackURL: process.env.HAYSTACK_URL}), new LogBackend({log: console.log.bind(console)})]
})

try {
  riskyThing()
} catch (error) {
  failbot.report(error, {
    extra: 'metadata',
    can: 'be',
    passed: 'as well'
  })
}

Report delivery

Failbot.report(error, metadata?, options?) returns one promise for each configured backend. Reporting is best effort by default, so delivery failures resolve to undefined. Configuration and payload preparation errors, including redaction errors, throw synchronously.

Set rejectOnError to reject with backend delivery errors:

await Promise.all(failbot.report(error, metadata, {rejectOnError: true}))

HTTPBackend treats fetch errors, timeouts, and non-2xx responses as delivery failures. Requests time out after 5 seconds by default. Set timeoutMs to configure the timeout:

const backend = new HTTPBackend({
  haystackURL: process.env.HAYSTACK_URL,
  timeoutMs: 1_000
})

Exception payloads

HTTP and log reports include a runtime-specific platform ("node" in Node.js and "javascript" in browsers) and a structured exception_detail by default. Stack frames from V8/Node/Chrome and Firefox/Safari are normalized to caller-first order for Failbotg. The legacy class, message, and string backtrace fields are also included for compatibility.

Consumers can override the default platform and exception_detail through metadata passed to report. The formatter continues to own the legacy error fields, timestamp, and JavaScript environment.

Generated structured exception fields redact the known credential patterns covered by Failbotg's global context filters, including URL basic-auth credentials, cookie values, sensitive key-value pairs, and GitHub tokens. This filtering intentionally preserves other exception content, such as email addresses and identifiers. Caller-provided exception_detail values are preserved verbatim by default, and legacy fields retain their existing values.

Application owners are responsible for keeping service-specific sensitive data out of exceptions. Configure a redact function when the application handles values that the default credential patterns cannot identify:

const failbot = new Failbot({
  app: 'my-cool-app',
  backends: [new HTTPBackend({haystackURL: process.env.HAYSTACK_URL})],
  redact(value) {
    return value.replace(/service-specific-sensitive-pattern/g, '[app redacted]')
  }
})

Built-in filtering runs on generated structured details. The custom function then runs on every JSON-serializable string in the outbound payload, including generated and caller-provided structured details, legacy fields, and metadata. It is not applied to sensitive_context. Use it for additional formats called out by GitHub's secure exception handling guidance, such as authorization and HMAC headers, JWTs, service credentials, and application-specific serialized data. The function must always return a string and must not throw. Add tests for application redaction rules, and record a metric or safe log entry when a rule matches so the underlying exception can be fixed.

Custom backend implementations receive the configured function as the third argument to report and must apply it before transporting exception data. The bundled HTTP and log backends do this automatically.

Exception metadata should use registered semantic conventions. Data that must be available in Splunk but must not reach Sentry can be placed in the Failbotg sensitive_context object:

failbot.report(error, {
  context: {'gh.example.repository.id': repositoryId},
  sensitive_context: {'gh.example.repository.path': repositoryPath}
})

Only use sensitive_context when retaining the value is necessary. Authentication data and other restricted content must be removed before reporting rather than sent through either context.

In order to attribute reported exceptions to service catalog services, the catalog_service tag is included in all exceptions reported via this library. Since all moda deployments have an OTEL_SERVICE_NAME environment variable, catalog_service is included in every failbot report payload as the value of OTEL_SERVICE_NAME.

You should not need to override this value but, if you do, you can pass catalogService to the Failbot constructor: const failbot = new Failbot({app: 'my-app', catalogService: 'my-catalog', backends: ...}). Be aware that overriding this value may make it impossible for your team to receive alerts related to high volumes of exceptions.