Skip to content
All articles

AI and automation

Scheduling launch countdowns and end dates from Claude

How to create a launch countdown bar from a prompt, get the timezone right, approve it before it goes live, and move or end it cleanly when plans change.

Provedly team··6 min read

A launch countdown has one job: tell visitors when something real happens, and be right about it. Most of the ways it goes wrong are about dates. The wrong timezone, an end time typed as 9pm instead of 9am, a launch that slips by a day while the bar keeps counting toward the old date. Creating and editing bars from Claude makes these changes quicker, and it is worth knowing exactly how dates are read so quick does not mean careless.

For the broader honesty rules around timers, see honest countdown timers. This post is about the mechanics from a chat.

Creating the bar

With Provedly connected through a read and write key, a single prompt does it:

Create a countdown bar for our winter launch ending Dec 1 at 9am. Message: "The winter collection opens in {timer}".

The assistant calls create_bar. Two things to know about the result.

It starts paused. Bars created through the API or MCP are never shown to visitors straight away. The assistant should say so and repeat back the name, message and end time it used. That is your review step.

The end time has a timezone. If you give a local time such as "Dec 1 at 9am", it is stored as 2026-12-01 09:00 and read in the bar's own timezone. If you give a full ISO 8601 timestamp, such as 2026-12-01T09:00:00-05:00, that exact instant is used.

Getting the timezone right

The local form is what most launches want. "Opens at 9am" in your marketing means 9am where your business is, and reading the end time in the bar's timezone matches that.

Problems start when the person typing is not in the store's timezone. A founder in Lisbon setting up a launch for a New York store, or an agency in one country working for a client in another. In those cases, be explicit:

Create the bar ending Dec 1 at 9am New York time.

or give the timestamp yourself. Then ask the assistant to show the end time it stored. If the answer is not what you meant, fix it before you switch the bar on, which is exactly what the paused start is for.

Once the end moment is stored, it is one fixed instant for everyone. A visitor in another timezone sees the same deadline, counted down from wherever they are, so you only need to get it right once.

Switching it on

When the details are right:

Looks good, turn it on.

The assistant calls set_bar_status and the bar goes active. Activation counts against your plan's bar limit, the same as in the dashboard. If you are at the limit, the request is refused with the reason, and you can pause another bar first.

If you have the one-line site snippet installed, which is rolling out now, the bar appears on the site without any code change. Without it, make sure the bar is installed on your site the same way your other bars are. The WordPress plugin already loads bars on every page for you.

When the launch moves

Launches slip. When yours does, move the end date once, to the new real time:

The launch moved. Change the winter launch end date to Dec 2 at 9am.

That calls update_bar. Update the message at the same time if it mentions a date. What you should not do is keep nudging the deadline forward each time it gets close. A countdown that resets is the classic fake-urgency pattern, and visitors who return and see the timer still running notice it. Honest urgency with an AI assistant covers how to keep requests like this honest.

When it ends

At zero, the countdown has done its job. Pause the bar, or replace it with something true for the next phase:

Pause the winter launch bar and create an announcement bar saying "The winter collection is live. Free returns until January 15."

The new announcement bar is created paused like every bar made through the API, so you approve it before it appears. Ask for a list of active bars afterwards to make sure the old countdown is not still running.

A pattern for recurring launches

If you launch on a rhythm, say a monthly drop, keep the bar instead of creating a new one each time. After each launch, pause it. Before the next one:

Update the monthly drop bar: end date Jan 5 at 10am, message "The January drop opens in {timer}". Leave it paused.

Then review and switch it on. The bar's history stays in one place, and the stats for each launch window are easy to pull with get_stats.

Frequently asked questions

What format should I use for the end date?

Either a local time like "2026-12-01 09:00", read in the bar's timezone, or a full ISO 8601 timestamp. Natural phrases like "Dec 1 at 9am" are turned into one of these by the assistant; ask it to show the stored value.

Can the bar switch itself on at a set time?

Bars created from a chat start paused and go live when you activate them. The end time is scheduled; the start is your decision.

What happens when the countdown reaches zero?

The countdown ends at that moment for every visitor. Pause the bar or replace it, so the page does not keep showing an offer that has finished.

Sign up free and try a launch countdown on the Free plan.

countdownlaunchescta barsmcp

Get new articles by email

Honest social proof, verified purchases and what actually moves conversion. A few emails a month at most; leave with one click.

We email you once to confirm. Your address is used only for this newsletter; see the privacy policy.

Show proof you can stand behind.

Free plan, one site, 2,000 impressions a month, verified purchases included. The badge on the free plan links to your verification page, which is the point.