We now send the errors from our own products, FeatureOS and SupportWire, to OpenFault, the error tracker we build at Skcript. The move took a handful of small pull requests, because OpenFault speaks the Sentry SDK protocol and most of the work was changing a DSN. Within a few weeks it showed us a launch crash in the SupportWire iOS app that we then fixed. This post covers what we changed, what we found, and what is still rough.

OpenFault is free and MIT licensed. You host it yourself, in one container with SQLite, and the official Sentry SDKs work with it. The code is on GitHub. One caveat up front: the server is in active development and is not production ready. We run it anyway because we build it and can fix what breaks.

Why we did it

If we ask other teams to trust an error tracker, our own products should be on it first. Running FeatureOS and SupportWire on OpenFault gives us real errors from real apps, on a web stack and on iOS. Synthetic test data does not give us that.

What we changed in each product

FeatureOS web app

The FeatureOS web app already reported errors through the Sentry SDK, to a Bugsink server. Moving it to OpenFault touched one file. We replaced a stale Sentry ingest host in the Content Security Policy with our OpenFault host, then updated the DSN in the deploy environment. Our rollback plan was one line: set the DSN back to the old value and redeploy.

FeatureOS onboarding

Once errors were flowing, we wanted the ones that cost us signups. A later change tags onboarding failures with flow:onboarding and the step they came from. It covers sign-in and OTP, sign-up, the organization picker, workspace setup, custom domain, branding, team invites and the onboarding checklist.

Two details mattered. The web app's error helper now drops 4xx responses, because a wrong OTP is a user mistake and not a fault. That filter applies to every caller of the helper, not just onboarding. On the API side, the sign-up and organization avatar error handlers used to post only to Discord. Now they also capture unexpected exceptions, and validation errors are still skipped.

SupportWire iOS app

In the SupportWire iPhone app, we added the official sentry-cocoa SDK and pointed it at OpenFault:

  • The DSN is an optional build setting. Leave it empty and reporting is off.
  • The SDK starts at launch with tracing and automatic sessions turned off, and tags each event with the environment and the app version and build.
  • One line in the API logger captures transport and decoding errors. Cancelled requests are skipped.
  • A Release-only build phase uploads dSYMs so crashes come back symbolicated. It only ever warns, so it can never fail a build.
  • Debug builds get a "Send test error to OpenFault" button in the developer settings.

What it caught

The first real catch came from the SupportWire iOS app. OpenFault recorded a launch crash in the app's Core Data setup: NSCocoaErrorDomain 512, Failed to create file, with an underlying "no such file or directory". The folder the database file lives in did not exist yet. Loading the store failed, and that failure went straight to a fatalError, so the app crashed instead of recovering.

The fix creates that folder before loading the store, for both the shared app group location and the default Application Support location. To be honest about it: OpenFault had recorded one event, from a debug build, and we did not reproduce the crash at runtime. We shipped the fix as the likely cause, not a confirmed one. Without a tracker on the app we would not have seen it at all.

What is still rough

  • dSYM uploads. In the first Release build, the automatic upload of the main app's dSYM got a one-off HTTP 400 from OpenFault. Sending the same file again by hand returned 200. We are looking into it on the OpenFault side.
  • iOS HTTP errors. The app captures transport and decoding failures, but not HTTP 4xx and 5xx responses yet.
  • The server itself. OpenFault is still in active development. We are the kind of user who can live with that. You may not be.

Should you do this?

It is a good fit if:

  • You already use the Sentry SDKs and want error tracking on a small box you control. In the repository's 10,000-event burst test (3,000 accepted, 7,000 rate-limited), we measured about 10 MB of memory idle and about 28 MB at peak on an Apple M5.
  • You can roll back with a DSN change, and you are fine reporting a bug when you hit one.

It is not a good fit if:

  • You need a production-ready tracker with guarantees today.
  • You rely on tracing or session replay. We turned tracing off in our own iOS setup.

If you are weighing options, we keep a plain comparison at openfault.dev/alternatives, and the steps for switching an existing app are at migrate from Sentry. There is also a free OpenFault iOS app for alerts on your phone, which we wrote about here.