How to Set Up a Time-Based QR Code
A café that serves breakfast, lunch and dinner usually prints three menus and one QR code that opens all of them in a long scroll. A time-based QR code does it the other way round: the same printed square opens the breakfast menu at 8am and the dinner menu at 7pm, and nobody reprints anything. This guide covers how to plan the windows, the four details that decide whether the code switches when you expect it to, and the one thing a single rule cannot do.
What a time-based QR code actually is
The pattern printed on the table tent cannot change. What can change is where it sends people. A dynamic QR code encodes a short redirect address instead of your menu’s address, and the redirect decides where to go at the moment of each scan. A time rule is one of those decisions: between these hours, open this page.
A static code can’t do this, because its destination is baked into the pattern. If your current code opens your menu’s address directly, a time-based setup means printing one new code once. After that, every change is an edit.
Plan the day before you build any rules
Write the timetable down first. Here is an example for a café; the hours are illustrative:
- 07:00–11:00 → breakfast menu
- 11:00–16:00 → lunch menu
- 16:00–22:00 → dinner menu
- Any other time → the code’s main destination: the full menu with your opening hours at the top
That last line matters most. Someone will scan the code at 6:45am, or at midnight from a photo they took last week. The main destination is what they get whenever no rule matches, so make it a page that is right at any hour, not a blank “closed” page.
Four details that decide whether it switches when you expect
1. The timezone
“Seven in the morning” means nothing to a server until it knows where. Each time rule carries a timezone, and the rule builder fills in the one your browser reports. Check it, especially if you set the code up while travelling. A rule with no timezone runs on UTC. In Edmonton during summer time that is six hours out, so a dinner window set for 20:00 would switch at 2pm local.
2. Where a window ends
A window includes its start minute and stops just before its end minute. 07:00–11:00 covers everything up to 10:59, and at 11:00 the lunch window takes over. So back-to-back windows can share a boundary time with no gap and no overlap, exactly as in the timetable above.
3. Windows that cross midnight
If the start is later than the end, say 22:00–02:00 for a late menu, the window wraps past midnight and covers both sides of it. You don’t need two rules for one late shift.
4. Overlaps and priority
Every rule has a priority from 1 to 10. At each scan the rules are checked from the highest priority down, and the first one that matches wins. So overlapping windows are fine as long as you mean them to overlap. A happy-hour page from 16:00 to 18:00 at priority 8 sits on top of a dinner window from 16:00 to 22:00 at priority 5: happy hour shows until 6pm, then dinner. If two overlapping rules have the same priority, don’t rely on which one wins. Give the one that should win the higher number.
Weekends, and the one thing a single rule can’t do
A day-of-week rule is its own rule: on these days, open this page. Each rule checks one condition, either the time or the day, never both at once. That means there is no single rule for “breakfast menu, but only on weekdays”.
Priority covers the common case. A weekend-brunch rule for Saturday and Sunday at a higher priority than your time rules shows the brunch menu all day on those two days, and the time rules run as normal Monday to Friday. What you can’t express is “brunch until 2pm on weekends, then dinner”, because the day rule doesn’t know the time. If you need that, the honest options are a brunch page that links to the dinner menu, or a separate code on the weekend table cards.
Seasonal menus are a third kind of rule, a date range (from this date to that date), and they follow the same priority order.
Test it before the table tents go out
- Check that each rule shows your timezone, not UTC.
- Scan a few minutes before a boundary and again just after it. 10:58 and 11:01 tell you more than any setting screen.
- Scan at a time no rule covers, and check that the main destination is a page you are happy for someone to see at midnight.
- Open each destination on a phone on mobile data. A menu PDF that takes eight seconds to load wastes the whole idea.
Every scan is checked against the rules at that moment, and the redirect tells the phone not to cache it. So a window you change in the afternoon applies to the next scan, and an old scan doesn’t keep serving the old menu.
What to print next to the code
Don’t label the code “Breakfast menu” if it opens dinner after 4pm. A plain “Scan for today’s menu” is true at every hour. The wider point, that the line beside a code is a promise the scan has to keep, is covered in what to put next to a QR code.
Where CreateQRCodes lands
Time-of-day and day-of-week routing are part of Pro and Business, and date-range (seasonal) routing is Business only. Rules attach to a dynamic code, run at every scan in the timezone saved on each rule, and are checked from the highest priority down, falling back to the code’s main destination when nothing matches. Each rule tests one condition. There is no combined time-and-day rule today, and this guide doesn’t pretend otherwise.
The rule types are on the routing page, and pricing shows which plan has which. For the restaurant side of it, see QR codes for restaurants and restaurants and bars. The restaurant menu template is a starting design for the code itself.
