Resolved Issue incorrectly marked as regressed by Sentry without explanation

[crossiatlas]

Environment

SaaS (https://sentry.io/)

Steps to Reproduce

We had a "No space left on device" error being thrown by one of our servers, which opened a new issue in Sentry. 7 occurrences were recorded, the most recent was Aug 28, 2025 00:27 UTC.

We fixed the root cause and marked the Issue as resolved at Aug 28, 2025 01:24 UTC (less than an hour later). All good.

We then received an alert exactly 7.5hrs later that Sentry had marked the issue as a regression (at Aug 28, 2025 08:54 UTC). We can find no explanation as to why this happened, the issue was fixed and we can't find any logs to indicate that it ever actually occurred again afterwards.

Expected Result

If the issue did not occur again after being marked as resolved, Sentry should not have reopened it and marked it as a false regression. If the issue did occur again, we would have expected the email to include the timestamp of an occurrence after 12:27am (or actually 1:24am when the issue was fixed).
At a minimum, we would expect the "Last Seen" timestamp to be after the time that the issue was marked as Resolved, not 7.5hrs beforehand. We would also expect to see an additional Event/Occurrence in the Issue history.

Actual Result

Notification email received from Sentry 7.5hrs after issue was resolved:

Note that it still says "Last seen at 12:27am UTC", which is the last recorded occurrence.

The error did not occur again after the issue was marked as resolved:

Product Area

Issues

Link

No response

DSN

https://e18e6af082454393ae92dd903156f886@o1014726.ingest.us.sentry.io/5982045

Version

No response

[linear]

ENG-5418 Resolved Issue incorrectly marked as regressed by Sentry without explanation

[getsantry]

Auto-routing to @getsentry/product-owners-issues for triage ⏲️

[scttcper]

Can you provide a link to this issue. Usually in the past when we've looked into these the errors are "stale" and we're receiving them late. We preserve the timestamp at which the events happened, but often there was a large delay between when the event happened an when we received them.

[crossiatlas]

Can you provide a link to this issue. Usually in the past when we've looked into these the errors are "stale" and we're receiving them late. We preserve the timestamp at which the events happened, but often there was a large delay between when the event happened an when we received them.

That definitely sounds plausible. We're using Sentry for Laravel, so I'm not sure if that (or the underlying Sentry PHP SDK) could be the cause. Unfortunately I can only be about 80% sure that the most recent of the 7 Events was there when I marked the Issue as Resolved (it was nearly a week ago, there's a small chance there was only 6 at the time and the 7th came through 7.5hrs later). I have a feeling that when the regression email arrived I was expecting to find an 8th Event, but there was still only 7. I can't be certain of this though.

Is there Issue ID combined with the above DSN enough? I'd rather not provide the full URL here as it includes a Client name.

The Issue ID is 6798409725

Edit: I was hoping to find more information than I could see via the Sentry UI, so I used the API to query the latest Event directly.

The response payload includes:

"dateReceived": "2025-08-28T00:27:19.196362Z",
"dateCreated": "2025-08-28T00:27:19.070049Z",

Does the dateReceived reflect the time that the issue was received by Sentry? If so, that means Sentry received it only ~125ms after it occurred. The original exception in our Cloudwatch logs shows a timestamp of 2025-08-28T00:27:19.064139+00:00, so that's maybe ~6ms for it to be handled by Sentry's PHP SDK (where the dateCreated was captured).

Looking at the Issue itself, I'm seeing:

    "openPeriods": [
        {
            "start": "2025-08-28T08:54:17.987777Z",
            "end": null,
            "duration": null,
            "isOpen": true,
            "lastChecked": "2025-08-28T00:27:19.070049Z"
        },
        {
            "start": "2025-08-08T09:04:00.459266Z",
            "end": "2025-08-28T01:24:33.339409Z",
            "duration": "1700432.880143",
            "isOpen": false,
            "lastChecked": "2025-08-28T01:24:33.339409Z"
        }
    ],

So it was closed at 01:24am, then reopened at 08:54am, but lastChecked still says 00:27am.

Interestingly, the activity section shows the regression being caused by a different Event ID than the most recent one:

    "activity": [
        {
            "id": "5102713142",
            "user": null,
            "sentry_app": null,
            "type": "set_regression",
            "data": {
                "event_id": "9333d5355d2d4940ab2499338c5bc63d",
                "version": ""
            },
            "dateCreated": "2025-08-28T08:54:17.987777Z"
        },

This Event is actually from several hours earlier.

If I query that event directly, it has:

"dateCreated": "2025-08-27T22:04:21.527841Z",
"dateReceived": "2025-08-27T22:04:21.773000Z",

So again, this Event doesn't seem to have come through late. It was reported to Sentry mere milliseconds after occurring. Somehow it triggered a regression exactly 10.5hrs later.

It's possible there's still something I can't see here and you'll be able to find a better explanation of what occurred at 8:54am UTC.