Scheduled Feature Releases: Ship at 3am Without Staying Awake

The 3am Deploy Problem

Feature flags scheduled releases solve one of the most painful problems in software delivery: timed launches across time zones. Every developer has been there. The product launch is scheduled for Monday morning in Tokyo, which means Sunday night in Berlin and Sunday afternoon in San Francisco. Someone has to be online to press the button.

The usual options:

1. Someone stays awake. An engineer watches the terminal at 3am, runs the deploy, monitors for errors, and hopes nothing breaks. If it does, they're debugging production while sleep-deprived.

2. You write a cron job. A scheduled CI/CD pipeline that triggers at the right time. It works until it doesn't — and when it fails, there's no one watching.

3. You deploy early and hope. Ship the code on Friday, pray the feature doesn't leak over the weekend, and flip a config value Monday morning. Now you've added the risk of accidental exposure.

None of these are good. They're workarounds for a missing tool: the ability to schedule a feature flag change for a specific date and time, with automatic rollback if something goes wrong.

How Scheduled Feature Flags Work

Scheduled feature flags separate deployment from release. Your code ships to production behind a flag that's turned off. You then schedule the flag to enable at a specific time — no deploys, no cron jobs, no humans required.

The concept is simple:

1. Deploy code with the feature wrapped in a flag (disabled by default)
2. Set a schedule — enable_at: 2026-04-01T00:00:00Z
3. Optionally set a disable time — disable_at: 2026-04-01T06:00:00Z for maintenance windows
4. The system flips the flag at the scheduled time
5. If something breaks, roll back to the previous state in one click

The flag evaluation happens on the server side. When the scheduled time arrives, the flag's state changes in the database. SDKs pick up the change via SSE (real-time) or polling (typically within 30 seconds).

Scheduled Releases with Rollgate: A Practical Example

Let's walk through a real scenario. You're launching a new onboarding flow for your SaaS product. The launch is planned for April 1st at 9am CET.

Step 1: Deploy Behind a Flag

Your code ships with the new onboarding wrapped in a feature flag:

import { useFlag } from '@rollgate/sdk-react';

function OnboardingFlow() {
  const useNewOnboarding = useFlag('new-onboarding-v2', false);

  if (useNewOnboarding) {
    return <NewOnboarding />;
  }
  return <LegacyOnboarding />;
}

This code deploys to production days or weeks before launch. The flag is off, so all users see the old onboarding. Zero risk.

Step 2: Test with Internal Users

In the Rollgate dashboard, you create a segment for your QA team — a list-based segment with their user IDs. You enable the flag for this segment only. QA tests the new onboarding in production with real data, real integrations, real edge cases.

Step 3: Schedule the Launch

In the dashboard, you set:

• Enable at: 2026-04-01T07:00:00Z (9am CET)
• Percentage: 100% of users
• Targeting: All users (remove QA-only restriction)

That's it. No one needs to be online at 9am. The flag enables automatically.

Step 4: Monitor and Roll Back if Needed

Your monitoring picks up a spike in errors 20 minutes after launch. The on-call engineer opens the Rollgate dashboard and clicks "Rollback." The flag reverts to its previous state — QA-only — in under 2 seconds. Users are back on the old onboarding while the team investigates.

On the backend, the same flag works with the Node.js SDK:

import { RollgateClient } from '@rollgate/sdk-node';

const client = new RollgateClient({
  apiKey: process.env.ROLLGATE_SERVER_KEY,
  enableSSE: true, // instant updates when the schedule triggers
});

await client.initialize();

app.post('/api/onboarding/start', async (req, res) => {
  const useNew = client.isEnabled('new-onboarding-v2', {
    id: req.user.id,
    attributes: {
      plan: req.user.plan,
      country: req.user.country,
    },
  });

  if (useNew) {
    return res.json(await startNewOnboarding(req.user));
  }
  return res.json(await startLegacyOnboarding(req.user));
});

When the scheduled time arrives, the SSE connection pushes the flag update to your server. The next request evaluates the flag as true, and the new onboarding is live — no restart, no redeploy.

Real-World Use Cases for Scheduled Feature Flags

Product Launches Across Time Zones

Schedule a flag to enable at 9am in each region. Use targeting rules to match users by country, so the feature rolls out at the right local time for each market.

Gradual Rollouts on a Schedule

Instead of manually increasing percentage rollout, schedule the stages:

• Monday 10am: 5% of users
• Wednesday 10am: 25% of users
• Friday 10am: 100% of users

If metrics drop at any stage, roll back before the next one triggers.

Maintenance Windows

Schedule a maintenance banner to appear at midnight and disappear at 6am:

const showMaintenance = useFlag('maintenance-banner', false);
// enable_at: 2026-04-05T22:00:00Z
// disable_at: 2026-04-06T04:00:00Z

No code changes, no deploys, no one staying awake to turn it off.

Pricing Changes

Switching to new pricing? Schedule the flag for the start of the billing cycle. All users see the new pricing page simultaneously, and if something is wrong with the display, roll back instantly.

Time-Limited Promotions

Black Friday sale that runs for exactly 48 hours? Schedule the enable and disable times. The promotion starts and ends automatically, and there's no risk of forgetting to turn it off Monday morning.

Beta Expirations

Give beta users access to a feature for 30 days. Set enable_at for today and disable_at for 30 days from now. When the beta period ends, the feature disables automatically and users see an upgrade prompt instead.

Best Practices for Scheduled Feature Releases

1. Always Have a Rollback Plan

Never schedule a release without knowing how to undo it. With Rollgate, 1-click rollback is built in — it restores the exact previous state including targeting rules, percentage, and flag value.

2. Deploy Code Well Before the Schedule

Ship the code behind a disabled flag days before the scheduled release. This separates deployment risk from release risk. If the deploy breaks something, you catch it before launch day.

3. Use Gradual Rollout with Scheduling

Don't go from 0% to 100% in one step. Schedule a gradual increase: 5% → 25% → 50% → 100% over several days. Each stage gives you time to monitor metrics and catch issues before they affect all users.

4. Test with Internal Segments First

Before scheduling a public release, enable the flag for an internal segment (your team, beta testers, or a QA group). Catch bugs in a controlled environment, then schedule the public rollout.

5. Set Alerts on Flag Changes

Use webhooks to get notified when a scheduled flag change triggers. Rollgate sends flag.scheduled and flag_state.updated events to your webhook endpoint, so your monitoring pipeline knows when a flag changed state.

6. Document Your Schedules

Use flag descriptions in the dashboard to note why a schedule was set. "Launch new checkout — coordinated with marketing email campaign at 10am CET" gives context to the next engineer who sees the flag.

Stop Losing Sleep Over Releases

Scheduled feature flags eliminate the operational overhead of timed releases. No more 3am deploys, no more cron jobs that fail silently, no more "who's going to flip the flag?"

Rollgate includes scheduled changes on every paid plan, starting at €39/month. The free tier (500K requests/month) includes everything except scheduling and rollback — enough to evaluate the platform and start wrapping features in flags.

Get started at rollgate.io or explore the live demo.

For more on feature flags, read our guides on what feature flags are, gradual rollout strategies, A/B testing with feature flags, and our feature flags pricing comparison. Switching from another tool? See our LaunchDarkly alternative and ConfigCat alternative guides.