How to schedule redirects that must point to different targets over time

A common requirement in redirect management is to serve a fixed URL that must point to a different target over time, with each target going live automatically at a precise moment. Typical cases include printed short URLs (flyers, packaging, ads) that cannot be reprinted every week, but whose destination changes on a weekly promotional cycle.

redirection.io handles this with the DATETIME trigger. However, the way rules are published means that a naive approach - editing a single rule week after week - produces a gap during which no redirect is served at all. This article explains why that happens and how to schedule overriding redirects correctly, using several rules and rule priority.

The use case

You have a stable, public URL, for example /weekly-offers. It is printed in advance and cannot be modified. Each week, it must redirect to a different target:

• until Sunday: /offers/week-A
• from Sunday onward: /offers/week-B

The switch must happen automatically at a defined date and time, and the previous target must keep working until that moment.

The common pitfall: editing a single rule

The intuitive approach is to keep one rule for the URL and, once a week, edit it to update two things:

• the DATETIME trigger (the new activation date)
• the target URL

This does not work, and the reason is important. When you publish a new version of a ruleset, the edited rule replaces its previous version. The former rule no longer exists in the published ruleset. If the new DATETIME trigger is set in the future (for instance after 05/07/26), then between the moment you publish and that future date, there is no rule matching the URL at all.

The consequence:

• the old target stops being served immediately upon publication
• the new target is not served yet, because its DATETIME condition is not met

During that interval the URL returns no redirect, which surfaces as errors for links that were expected to still resolve to the previous target.

You can confirm the gap in the rule tester (Rules > Test a specific request). Testing the URL for a date that falls after publication but before the new activation date returns no match:

The solution: one rule per period, plus priority

Create one rule for each time period, instead of editing a single rule:

• rule A: URL /weekly-offers + DATETIME after <start of week A> -> target for week A
• rule B: URL /weekly-offers + DATETIME after <start of week B> -> target for week B

Both rules can be prepared and published well in advance. There is no gap, because rule A remains active continuously until rule B's activation date is reached.

After that date, however, things become less evident: will rule A be executed, or rule B? Once the current date is past both start dates (for example on the 8th of July, when both after 29/06 and after 06/07 match), both rules are triggered. You must therefore set rule priority so that the rule covering the most recent period takes precedence.

In redirection.io, assign a higher priority to the rule with the later activation date. When several rules match, the one with the higher priority is applied, so the destination always corresponds to the latest period that has started.

You can verify this while creating new rules for new periods. Provided you have configured correct examples in your rule, the "impact" step allows to organize rules priorities:

An example with three periods

The following ruleset defines three targets for three consecutive weeks on the same URL:

Trigger	Action (target)	Priority
URL /example + DATETIME after 29/06/26 00:00	/week-29th-june	0
URL /example + DATETIME after 06/07/26 00:00	/week-6th-july	1
URL /example + DATETIME after 13/07/26 00:00	/week-13th-july	2

Behaviour over time:

• between 29 June and 6 July: only the first rule matches -> /week-29th-june
• between 6 July and 13 July: the first two rules match, priority 1 wins -> /week-6th-july
• from 13 July onward: all three match, priority 2 wins -> /week-13th-july

The later the activation date, the higher the priority, so each new period cleanly overrides the previous one at the exact moment it starts.

Verify before it goes live

Because the switch is time-based, you do not have to wait for the real date to check it. Use the rule tester and add a DATETIME restriction set to a future moment to simulate that date.

For example, testing /weekly-offers with Datetime is 08/07/2026 00:00 shows which rule(s) will be applied on that day, the resulting target URL, and the full list of matched rules in the order they are evaluated. This lets you validate the entire schedule in advance:

Summary

To schedule redirects that override an existing rule without any downtime:

1. Do not edit a single rule to change its date and target. Publishing replaces the rule and creates a gap until the new activation date.
2. Create one rule per period, each matching the same URL with its own DATETIME after condition and its own target.
3. Give a higher priority to the rule with the later activation date, so the most recent period wins when several rules overlap.
4. Validate the schedule ahead of time with the rule tester by simulating a future DATETIME.

This approach lets you prepare every target weeks in advance, keep fixed public URLs untouched, and have each redirect take over automatically at the exact scheduled moment.