Sentry's SDK hooks into your runtime environment and automatically reports errors, exceptions, and rejections.

The most common form of capturing is to capture errors. What can be captured as an error varies by platform. In general, if you have something that looks like an exception it can be captured. For some SDKs you can also omit the argument to capture_exception and Sentry will attempt to capture the current exception. It can also be useful to manually report errors or messages to Sentry.

Separately to capturing you can also record the breadcrumbs that lead up to an event. Breadcrumbs are different from events: they will not create an event in Sentry, but will be buffered until the next event is sent. Learn more about breadcrumbs in our Breadcrumbs documentation.

Capturing Errors

To capture an event in Go, you can pass any struct implementing an error interface to CaptureException(). If you use a 3rd party library instead of native errors package, we'll do our best to extract a stack trace.

The SDK is fully compatible with (but not limited to):


If there is an errors package that's not working out of the box, let us know!

f, err := os.Open("filename.ext")
if err != nil {

Capturing Messages

Another common operation is to capture a bare message. A message is textual information that should be sent to Sentry. Typically messages are not emitted, but they can be useful for some teams.

sentry.CaptureMessage("Something went wrong")

By default, Sentry's Go SDK uses an asynchronous transport. That means that calls to CaptureException, CaptureEvent, and CaptureMessage return without waiting for network operations. Instead, events are buffered and sent over the network in a background goroutine. Call sentry.Flush to wait for event delivery before the program terminates. You can change the default behavior by using a different transport, for example HTTPSyncTransport. More details in the Transports section.

You can edit this page on GitHub.