Sent events but nothing shows in Sentry? Diagnose the real causes, from a wrong or malformed DSN and blocked network requests to environment filters and inbound filtering, with fixes in order of likelihood.
This problem is distinct from unsymbolicated crashes or missing crashes specifically. Here, nothing arrives at all: you triggered an error or captured a test message, but the Sentry dashboard's Issues view stays empty. Because you are getting no events of any kind, the failure is in the pipeline between your app and Sentry's ingest servers, not in crash handling or symbolication. The good news is that this narrows the search considerably. Either the SDK never actually sent the event, the event was sent to the wrong place, the network prevented it from arriving, or Sentry received it but filtered or routed it somewhere you are not looking. The single most effective first step is to enable the SDK's debug logging so you can see whether it even attempts to send and what response it gets. From there you work through the handful of causes systematically. Most cases resolve to a wrong DSN, a network or App Transport Security problem, or looking at the wrong project, environment, or time range in the dashboard.
Before guessing, make the SDK tell you what is happening. In your SentrySDK.start configuration set options.debug to true. On the next run, watch the Xcode console. A healthy SDK logs that it initialized, that it captured an event, and that it sent the event with a successful response. If you see it initialize but never attempt to send, the problem is upstream, perhaps the capture call is not running or the SDK was not started. If you see it attempt to send but receive an error such as a rejected key or a network failure, that error points directly at the cause. This one setting turns a blind investigation into a guided one and is worth doing first every time. Capture a deliberate test event, for instance SentrySDK.capture(message: "pipeline test"), so you have something predictable to trace through the logs. Once you can see in the console exactly where the event stops, whether at capture, at send, or at the server response, you know which of the following causes to focus on.
The DSN is the address the SDK sends events to, and if it is wrong, events go nowhere or to the wrong project. Common mistakes include copying the DSN with surrounding whitespace or quotes, using a DSN from a different project or organization, using a revoked or disabled client key, or leaving a placeholder string in place. Because a malformed DSN often causes the SDK to fail quietly, this is a leading cause of no events. Open your Sentry project settings under Client Keys (DSN) and copy the current, active DSN exactly, then compare it character for character against what your code uses. If the DSN points at a different project than the dashboard you are watching, your events are arriving, just not where you are looking, so also confirm you are viewing the same project the DSN targets. With debug logging on, a bad key typically produces a clear rejection response you can see in the console. Fixing the DSN, and confirming project alignment between the DSN and the dashboard, resolves a large fraction of these cases immediately.
Even with a perfect DSN, the request has to leave the device and reach Sentry. Several things can block it. App Transport Security enforces secure connections; Sentry's endpoints use HTTPS so a standard configuration works, but a custom, overly restrictive ATS configuration in your Info.plist, or a misconfigured exception, can interfere with outbound requests. A custom URLSession, a network interception library, or a debugging proxy in your app can also swallow or redirect the Sentry request. On the environment side, corporate Wi-Fi, VPNs, firewalls, and content filters sometimes block the Sentry ingest domain, so a device on a restricted network may fail to send while the same build on a normal connection succeeds. Test on a plain, unrestricted network to rule this out. The debug logs will usually show a network error if the request cannot complete. Also confirm the device actually has connectivity at the time; an offline device queues events and sends them later, which can look like nothing is arriving until the connection returns and the backlog flushes.
Frequently the events are arriving perfectly well, but the dashboard is filtered so you do not see them. Sentry's Issues view has filters for environment, for date and time range, and for search queries, and any of these can hide your events. If you set options.environment to something like "development" in your build but the dashboard is filtered to show only "production", your events are there but invisible. Similarly, a narrow time range, or a leftover search query filtering by a tag or release, can exclude exactly the events you are looking for. Reset the dashboard filters: set the environment selector to all environments, widen the date range to include the last hour or day, and clear any search query. Then look again. This cause is easy to overlook precisely because nothing is actually broken; the pipeline works and the events exist, but the view is scoped away from them. Whenever debug logging shows a successful send but the dashboard looks empty, suspect a filter mismatch before assuming events were lost.
Sentry can accept an event and then drop or hold it based on server-side rules, which also produces an empty-looking dashboard. Check your project's Inbound Filters in settings; filters for specific releases, environments, error messages, or legacy browsers, and options like filtering events from certain sources, can discard incoming events before they become issues. If someone configured a filter to reduce noise, it may be catching your test events too. Also consider quota and rate limiting: if your organization has exhausted its event quota for the billing period, or a per-key rate limit is in effect, Sentry may reject or drop events, and this is visible in your organization's stats and usage views. A client-side beforeSend callback returning nil will likewise prevent events from ever being sent, so review that too. Between client-side beforeSend, server-side inbound filters, and quota limits, there are several points where a well-formed event can still be discarded. Check each: confirm beforeSend is not dropping the event, review inbound filters, and verify you have remaining quota for the current period.
Put these together into a repeatable sequence and you will find the cause quickly. Start by enabling debug logging and capturing a known test message, then read the console to see how far the event gets. If the SDK never attempts to send, confirm SentrySDK.start actually ran and your capture call executed, and check for a beforeSend returning nil. If it attempts to send but gets a key rejection, fix the DSN and confirm it matches the project you are viewing. If it reports a network error, test on an unrestricted connection and review any ATS or custom URLSession configuration. If the console shows a successful send but the dashboard is empty, the pipeline works, so turn to the dashboard: reset environment, date range, and search filters, then check inbound filters and your event quota. Working outward from the client to the network to the server-side view in this order isolates the problem without guesswork. Keeping this client-to-network-to-dashboard order in mind prevents the common mistake of rewriting SDK configuration when the events were arriving all along and only a dashboard filter was hiding them. In practice, the overwhelming majority of no-events cases are a wrong DSN, a blocked or offline network, or a dashboard filtered away from the events, and this sequence catches all three fast.
Set options.debug to true in your SentrySDK.start configuration and watch the Xcode console. It logs initialization, event capture, and send attempts with their responses. This shows whether the event stops at capture, at the network, or is accepted, telling you exactly which cause to investigate.
Yes, this is a leading cause. A DSN with stray whitespace, from the wrong project, or revoked will send events nowhere or to a project you are not viewing. Copy the active DSN from your project's Client Keys settings and compare it exactly, and confirm the dashboard shows the same project the DSN targets.
The dashboard is probably filtered away from them. Check the environment selector, the date and time range, and any search query in the Issues view. If your build uses environment development but the dashboard filters to production, the events exist but are hidden. Reset filters and widen the time range.
A standard ATS configuration allows Sentry's HTTPS endpoints. But an overly restrictive custom ATS setup, a custom URLSession, or a debugging proxy can interfere with outbound requests. Restricted corporate networks, VPNs, or firewalls can also block the ingest domain. Test on a plain, unrestricted connection to rule this out.
Yes. Server-side inbound filters can discard events by release, environment, or message, and an exhausted event quota or rate limit can cause Sentry to drop them. Also check that a client-side beforeSend callback is not returning nil. Review inbound filters and usage stats in your project and organization settings.