We’re Fly.io. We put your code into lightweight microVMs on our own hardware around the world, close to your users. We partnered with Sentry 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 credits. Check us out—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 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. 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, session replay, alerting and much more.
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 feature. We’ll also send events like out-of-memory errors to Sentry. The possibilities are endless.
Got ideas or comments? Get in touch on our community forum.