Analyze6 min read
Date ranges and comparisons
One range picker drives every page in the dashboard. It resolves the same way everywhere, so a bookmark, a reload, and a deep link from a saved report all show the range they say they show.
The presets
| Preset | What it means |
|---|---|
| Today | The current calendar day. |
| Yesterday | The calendar day before today. |
| Last 24 hours | A rolling 24-hour window ending now, not the same as Today, which resets at midnight. |
| Last 7 / 30 / 90 days | N whole calendar days ending today, inclusive. |
| Week to date | Monday through today, in the current week. |
| Month to date | The 1st of the month through today. |
| Last 12 months | 365 calendar days ending today. |
| Custom | Any start/end pair you pick. |
What "today" means
Today, Yesterday, Week to date, and Month to date are calculated against a timezone: either one you've set explicitly under account settings, or your browser's timezone if you haven't. That's what makes "Today" mean your today rather than a UTC one.
Daily data underneath is bucketed by UTC calendar day. For most timezones this is invisible, but if you're a long way from UTC, activity right around your local midnight can land in what the picker calls "today" or "yesterday" a little differently than your wall clock would suggest. Rolling windows (Last 24 hours, Last 7/30/90 days) don't have this wrinkle: they're exact durations, not calendar labels.
Comparison periods
Turning on Compare measures every KPI against the immediately preceding period of equal length: Last 30 days compares against the 30 days before that; a custom 9-day range compares against the 9 days before it. There's no option to compare against an arbitrary other range or the same period last year.
How fresh the numbers are
Anything you can observe here is a direct consequence of caching, so it's worth knowing the two rules:
- A range that includes today recomputes automatically once the cached value is more than 10 seconds old, so live numbers never lag by more than about that.
- A range that's entirely in the past is immutable (it can't change), so it's served from a 60-second cache without recomputing, which is also the lowest TTL Mrkr's cache layer supports.
On top of that, the Overview page itself polls for new data every 30 seconds while it's open, and the Events live feed polls every 5 seconds, so what you see updating on screen is a mix of the poll interval and the underlying cache freshness above.
Custom ranges and persistence
Your last-picked range is written into a cookie, so a bare navigation (a bookmark, a reload, a link from your own docs) keeps showing what you had open rather than resetting to a default. Anything in the URL always wins over that cookie: an explicit ?days= or ?start=&end= in a link overrides your saved preference for that visit.