---
title: "Automated Sentry Error Tracking"
description: "Automated Sentry Error Tracking"
---

# Automated Sentry Error Tracking

[Annie Ruygt](https://annieruygtillustration.com/)

We’re Fly.io. We put your code into lightweight microVMs on our own hardware [around the world](https://fly.io/docs/reference/regions/), close to your users. We partnered with [Sentry](https://sentry.io) to bring error and performance monitoring to your apps. Deploy your first app, and automatically get a year’s worth of credits to Sentry’s [Team Plan](https://sentry.io/pricing/) credits. [Check us out](https://fly.io/docs/speedrun/)—your app can be deployed and instrumented in minutes.

We’ve been using Sentry since the dawn of the internet. Or at least as far back as the [discovery](https://home.cern/science/physics/higgs-boson/how) of the Higgs boson. Project to project, the familiar Sentry issue detail screen has been our faithful debugging companion.

Today it’s no exception: All of our Golang, Elixir, Ruby and Rust services report dutifully to Sentry.

So, it felt natural to integrate Sentry as the default error monitoring tool. All new deployments on Fly.io get a Sentry project provisioned automatically. Existing apps can grab theirs with `flyctl ext sentry create`.

Each Fly.io organization receives, for one year, a generous monthly quota:

- 50,000 Error events
- 100,000 Performance units
- 500 Session Replays
- 1GB of storage for Attachments

Once your app is instrumented, you’ll automatically get notified of production errors, latency issues, and crashes as soon as they occur in production. Sentry’s Team plan also gives you access to over 40 integrations, unlimited seats, and custom alerting.

## Auto-instrumenting Rails

To see Sentry in action, let’s launch our [Boomer Rails App](https://github.com/fly-apps/boomer). Yes kids, Rails is old school, and it’s the easiest framework to auto-instrument.

When `flyctl launch` detects a Rails app, it’s automatically setup to use a freshly minted Sentry project. Gems are installed, initializers planted, and finally, the `SENTRY_DSN` secret is set for deployment. We redacted some output for brevity.

```
fly deploy
```

```
==> Verifying app config

...

Your Sentry project is ready. See details and next steps with: flyctl apps errors

Setting the following secrets on boomerang:
SENTRY_DSN

...

Visit your newly deployed app at https://boomerang.fly.dev/
```

Now, having Sentry configured at launch time means that deployment errors are captured early. This is useful for situations where apps fail to boot, run out of memory, and so on.

Now let’s force an application exception. We visit the app root, which goes Boom, thanks to some hastily written Ruby code.

```
flyctl open
```

Oh shucks. Something went wrong. But, I got an email about this error.

We could click “View on Sentry”. Instead, let’s use `flyctl` to send us to the Sentry issues dashboard.

```
flyctl apps errors
```

We click through to this specific issue.

We successfully debugged our issue. The takeaway: don’t raise when you can call.

Error tracking on Sentry is just scratching the surface. Check out their [performance monitoring](https://docs.sentry.io/product/performance/), [session replay](https://docs.sentry.io/product/session-replay), [alerting](https://docs.sentry.io/product/alerts/) and [much more](https://docs.sentry.io/product/).

## Next Steps for Fly.io and Sentry

For our next trick, we’ll be tracking Fly.io releases in Sentry, so Sentry can link issues to their [release tracking](https://docs.sentry.io/product/releases/) feature. We’ll also send events like [out-of-memory errors](https://fly.io/docs/getting-started/troubleshooting/#out-of-memory-oom-or-high-cpu-usage) to Sentry. The possibilities are endless.

Got ideas or comments? Get in touch on our [community forum](https://community.fly.io/).