Bug Reporting for Games With Daily Quests and Streaks

Daily quests and streaks run on the clock, and clocks are where bugs hide. Players report that their streak broke even though they played, that today's quests never refreshed, that a milestone reward never arrived, and these are some of the most maddening reports to triage because they hinge on time: server time, device time, timezone, and the exact moment a reset boundary was crossed. The player experienced an outcome at a moment they cannot precisely state, and you cannot reproduce it without the timing. This post covers what goes wrong with daily systems and what to capture so a broken-streak report becomes a precise question about reset boundaries rather than a guessing game.

Why streak bugs are timezone bugs

A streak counts consecutive periods of activity, and the definition of a period is where everything goes wrong. If the reset boundary is computed in server time but the player thinks in their local time, a player who plays every evening can appear to skip a day across a timezone offset. If the boundary uses the device clock, a player who travels or whose clock is wrong can break or inflate their own streak. The player reports an unfair break, and they are usually right that they played, but right relative to a different clock than the one the streak logic used.

These bugs are invisible from the description because the player does not know which clock the game used or what offset their timezone introduced. You stand in your own timezone, play two days in a row, and the streak holds, because you never crossed the boundary the way they did. Capturing the player's timezone, their device clock, the server time, and the timestamps of their last qualifying action and the last reset turns it from did my streak break wrongly into a precise comparison of which boundary fell between which actions.

Quests that will not refresh

The mirror-image bug is a daily reset that did not happen: yesterday's quests are still showing, today's never appeared, or the refresh fired but the UI did not update. This is a question of whether the reset job ran, whether the client recognized that a new period began, and whether the two agree. A client that computes the next reset time wrongly, or caches the quest set past its expiry, or misses a reset because it was offline across the boundary, all produce stuck quests. The player reports stale quests, and you need to know when the last reset was supposed to fire versus when the client last refreshed.

Capture the scheduled next-reset time, the timestamp of the last actual refresh, and the current period identifier the client believes it is in. When those disagree with the server's notion of the current period, you have found the desync and can see whether the client is behind, ahead, or never recomputed. Offline-across-the-boundary is an especially common case: a player who left the game open overnight returns to yesterday's quests because nothing recomputed the period on resume. Capturing the resume-time recomputation, or its absence, points straight at that gap.

Rewards that do not grant at the boundary

Streak milestones and daily completion rewards grant at the reset or completion boundary, and grants that straddle a boundary are fragile. A reward might compute against a streak value that the reset is simultaneously updating, fire twice because two systems both noticed the completion, or fail because the grant ran before the streak increment it depended on. The player reports a missing or duplicated reward, and as with progression XP, you need the grant as an event with its inputs to see whether it fired, when, and against what state.

Log reward grants as events with the streak or completion state they read and a timestamp relative to the reset. A report showing a milestone reward computed against a streak of seven when the player reached seven, granted zero immediately suggests an ordering bug where the grant ran before the increment. The duplicate case, two grants for one completion, shows up just as clearly. Treating boundary-time rewards as logged events with their inputs is what lets you distinguish a true grant failure from a player who simply has not met the condition yet.

Designing the daily systems report payload

Settle on a time-aware snapshot that ships with every daily quest or streak report. Include the player's timezone, the device clock, the server time, the current streak count, the timestamp of the last qualifying action, the last reset timestamp, the scheduled next reset, the current period identifier, and any recent reward grant events. With that you can place every action and reset on a single timeline and see exactly which boundary fell where. The timing data is what converts these otherwise unreproducible reports into a clear sequence.

Keep the snapshot focused on the time-relevant fields so it stays cheap to attach automatically. The aim is that a player who feels the clock cheated them just hits report, and you receive enough timing to reconstruct the boundary crossing without asking them what time zone they are in or when exactly they played. Consistent fields enable aggregation too: counting broken-streak reports clustered around a specific UTC offset reveals a timezone-handling bug, and counting stuck-quest reports from players who were offline across the reset isolates the resume-recomputation gap.

Setting it up with Bugnet

Bugnet captures your daily and streak state automatically when a player taps the in-game report button, so the timezone, clocks, streak count, reset timestamps, and current period arrive as custom fields with no upload code. A player whose streak broke unfairly just reports it, and you receive the timing needed to see which boundary fell between which actions, alongside the device and platform context that often explains a wrong device clock. Because the time data arrives with the report, you skip the painful back-and-forth of asking an upset player to recall exactly when they played and in what timezone.

Daily-system bugs cluster around specific offsets and specific reset edge cases, and occurrence grouping makes that a clear signal. Bugnet folds duplicate reports into one issue with a count, and you can filter by a timezone_offset or period custom field to find the systemic cause. When fifty broken-streak reports share one UTC offset, that single issue rises by occurrence count and tells you the timezone math is wrong for a whole region, so you fix the boundary calculation once rather than triaging fifty individually-confusing complaints about a streak that should not have broken.

Testing reset logic across clocks

Once reports carry the timing, you can write tests that pin a fake clock and assert the reset behavior across timezones and boundary edges: a player active just before midnight local time keeps their streak, a player who skips a full period loses it, and a reset at the boundary refreshes the quest set exactly once. Each fixed daily-system bug becomes a permanent assertion, which matters because reset logic is full of off-by-one boundary cases that are easy to break and hard to notice until a region of players loses streaks overnight.

Be especially thorough around the boundaries that real life creates: daylight saving transitions, players who travel across timezones, devices with wrong clocks, and sessions that span the reset while offline. Keep capturing real timing from the field so your tests cover the offsets and edge cases your players actually hit, which are never only the tidy ones. Daily quests and streaks are a core retention mechanic, and treating their bugs as precise timing questions is what lets a small team keep that mechanic feeling fair across every clock in the world.

A broken streak is a boundary crossing on the wrong clock. Capture the timezones and reset timestamps and an unfair break becomes a precise, testable timing question.