Scheduled Releases with Feature Flags: Launch at 9am Without Anyone Awake

Marketing wants the feature live at 09:00 on launch day. Who is going to be at the keyboard?

The usual answers are all bad. Someone sets an alarm and clicks the toggle by hand. A cron job calls the flag API and nobody notices it failed. A deploy is timed for 08:55 and now the riskiest part of the week happens under a deadline. Each of these couples a marketing date to a human or a pipeline that can be late, sick or broken.

Then there's the multi-service problem. If the launch spans an API, a web app and a mobile client, three separate switches have to move together. A minute of skew is a minute of the app showing a feature the backend rejects.

Put the date in the rule, not on the calendar

A flag's targeting rules can compare against time, the same way they compare against a plan tier or a region. Featureflow stamps every evaluation with a featureflow.date attribute, and the after and before comparators match on it. So the launch is one rule, written days ahead:

Feature: new-pricing-page

Rule 1:  if featureflow.date after 2026-10-01T09:00:00Z  →  on
Default: for all users                                    →  off

The code is nothing special. Deploy it whenever you like, and evaluate the flag on the request path as normal. This is the Featureflow Node SDK; the same shape works with every SDK:

import Featureflow from 'featureflow-node-sdk';

const featureflow = new Featureflow.Client({
  apiKey: process.env.FEATUREFLOW_SERVER_KEY,
  // If the rules can't be fetched, the launch stays closed — never early.
  withFeatures: [new Featureflow.Feature('new-pricing-page', 'off').build()],
});

app.get('/pricing', (req, res) => {
  const user = new Featureflow.UserBuilder(req.user.id)
    .withAttribute('plan', req.user.plan)
    .build();

  // featureflow.date is set at the moment of this call, per request.
  if (featureflow.evaluate('new-pricing-page', user).isOn()) {
    return res.render('pricing-v2');
  }
  return res.render('pricing');
});

At 09:00 UTC the rule starts matching and every server, function and client evaluating this flag flips in the same instant. There is no button, no job to monitor, and no deploy on launch morning. The deploy happened on Tuesday, when nobody cared.

Use the built-in date, not your own timestamp

featureflow.date is a built-in context value. You do not set it and you should not try to — it exists specifically to make scheduled rollouts work, and it is optimised for both server and client delivery.

The tempting alternative is to put your own timestamp on the user context and write the rule against that. Don't. Evaluation responses are cached at the CDN, and the cache key includes the context you send. A timestamp changes on every single request, so every /evaluate call becomes a cache miss — you lose the CDN entirely and every request goes to origin.

This matters most for client-side evaluation, which is where the CDN is doing the most work for you. The Featureflow SDKs handle it with partial evaluation: the server resolves everything it can and returns a response that stays cacheable, leaving the date comparison to be finished on the client at the moment it is read. The rule still flips at 09:00 for everyone, and the response in front of it is still shared.

So: write featureflow.date in the rule, send the user context you would send anyway, and let the SDK do the rest.

Three details that decide whether it works

• Don't hand-roll the date. Leave featureflow.date to the SDK. A timestamp you put on the user context yourself will work in testing and quietly cost you the CDN cache in production.
• Write the timezone down. A date-only value such as 2026-10-01 means midnight UTC. If launch is 09:00 in Sydney, put the offset in the value rather than doing the arithmetic in your head.
• Keep the kill switch. A scheduled rule is still a rule. If the launch goes wrong, turn the feature off and the schedule is void until you say otherwise.

Stack the rules for a staged launch: internal users now, one region after the date, everyone a week later. Each step is visible in the flag's history with who set it and when, and with approvals turned on, the launch config is reviewed before it is saved, not at 08:59.

👉 Featureflow supports date comparators in targeting rules on every SDK, with an audit trail on every change. See the targeting docs or start at featureflow.com.

#FeatureFlags#ContinuousDelivery#ReleaseManagement#DevOps#ProgressiveDelivery