Skip to content

Prices are not reaching your property system

14 min readWhen something looks wrongUpdated October 8, 2026

In plain words

Give a new price two cycles, about ten minutes, then open the Change Log tab. A problem that needs you, such as a lost connection or a rate rule in your system, sits at the top at once as "Prices not reaching Cloudbeds", with the cause and what to do. One that clears on its own is shown only if it lasts 2 hours, first prices waiting for a read of your own rates after an hour, and a time zone mismatch usually not at all. Nothing is sent while you are simulating, nothing is ever sent to Mews, a price of 0 is never sent, and a night past the 396-night window (tonight and the next 395) waits until it enters it.

I went live and nothing is being sent

Check these in order.

  1. Wait two cycles. Prices go out about every five minutes, and only prices that changed since the last send. The first send to a night MAYA has never sent to also waits until a fresh read of your own rates has succeeded, within the last hour, so that MAYA writes over a rate it has freshly read. The first live cycle reads your rates before it sends. If that read has not worked for an hour, the change log says "MAYA couldn't read your current rates in Cloudbeds" at the top.
  2. Check that you are live. Look at the top of the dashboard. A slim amber strip reading "Simulation · MAYA works out prices but sends nothing to Cloudbeds" means you are simulating, and nothing is sent until a General Manager or Hotel Admin clicks its Go live. A small green Live tag means you are live. In the change log, the newest change for a night says "Sent to Cloudbeds." once its price went, or "Waiting to be sent to Cloudbeds." until it does. Going live says how to go live, and Tell whether you are live or in simulation has the other clues.
  3. Look for a problem item. On the Change Log tab, an ongoing problem sits above every run, headed "Prices not reaching Cloudbeds" (or "Prices not reaching Think Reservations"), with the cause and what to do. When your property system does not accept a price explains each. For a price you typed, the line under the price box on the calendar says the same for that one night: "Sent to Cloudbeds.", the real count of tries left, or "This price couldn't be sent to Cloudbeds." once MAYA has stopped retrying it, with Try again and either See the error log or the cause written under it. Setting a price yourself has the lines.
  4. Check the connection. Open the PMS tab and read the Connection card. Error or Disconnected means your system stopped accepting MAYA's connection, and nothing is read from it or sent to it while that lasts. Disconnected lasts until a General Manager or Hotel Admin reconnects. On Error MAYA keeps trying, and the card goes back to Connected by itself once a try works. If it has not cleared within a couple of hours, reconnect. Do not wait for the amber banner at the top of the dashboard, "MAYA has lost its connection to Cloudbeds": it shows only once the connection is marked as lost, and some breaks never are. Connection lost explains each status, and what an old Last sync means.
  5. Check the subscription. A red banner reading "MAYA has paused work on this property" means your rules no longer run on a schedule and nothing is sent to your PMS until the subscription is running again. Read Account and billing problems.

MAYA writes one nightly rate per room type to that room type's : the rate plan that does not follow another plan and has no public name. Cloudbeds takes the write as a job, and MAYA asks Cloudbeds whether the job applied. Packages and derived plans are never written; derived plans follow the base rate by Cloudbeds' own rules.

MAYA shows a new price but Cloudbeds still has the old one

Five reasons, most common first.

  • It has not gone yet. A price changed in the last few minutes goes on the next cycle. The first send to a night waits for a fresh read of your rates.
  • You are simulating. Prices are worked out and shown, and never sent. See the check above.
  • A problem is holding it. Look for "Prices not reaching Cloudbeds" at the top of the change log. The item says what is wrong and what to do.
  • Cloudbeds took it and never finished. Cloudbeds applies a rate write as a job. If a job is still unfinished 45 minutes later, or Cloudbeds never reported on it and still has a different rate there 3 hours to a day later, MAYA treats it as not applied and sends the night again. You are told only if it keeps happening.
  • ThinkReservations applies it later. ThinkReservations accepts a write and applies it afterwards. MAYA confirms it on the next hourly read. If that read still finds the rate from before the send 3 hours later, MAYA sends the night again.

My base rate moved but my non-refundable rate did not

MAYA writes its price to one rate per room type: the in Cloudbeds, and in ThinkReservations the one the PMS tab names after "MAYA reads and writes:". On Cloudbeds your non-refundable rate, like every other plan, moves only by Cloudbeds' own rules, and MAYA never writes to it. On ThinkReservations a non-refundable rate type with rates of its own is one of your other standard rate types, which the ThinkReservations tab below describes.

Check three things in your system.

  1. The base rate itself. Open the night. If the base rate still shows the old price, the new one has not landed yet. Read the five reasons above.
  2. Whether the non-refundable rate follows the base. A plan set to follow another is what both systems call derived. Only a derived plan moves when the rate it follows moves. A plan with rates of its own stays where you set it, whatever MAYA sends.
  3. What it follows, and by how much. A derived plan follows one rate, by the amount set in its own settings. If it follows a different plan, or the amount is not what you expect, change that in your system.

At The Harbour Inn, "Non-refundable" follows Standard Rate at 10% off. On Fri, Nov 13 2026, "Busy nights" raises Standard from $150 to $165, and MAYA sends $165 to Standard Rate. Cloudbeds moves Non-refundable from $135 to $148.50 on its own. MAYA wrote only the $165.

To make your non-refundable rate move with MAYA's price, set it in your system to follow the rate MAYA writes to. Your system then works it out from each new base rate.

MAYA writes only the base rate: the plan that follows no other plan and has no public name. A derived plan built on it moves once Cloudbeds has applied the new base rate. A non-refundable plan that follows nothing has rates of its own. MAYA never writes to it, so it keeps them.

Why did MAYA overwrite the rate I set in Cloudbeds?

On a live property whose setting is Keep the change as your price (as every property starts), a rate you change in your system is kept as a when all of these hold: the night is one MAYA had already sent to, MAYA's send there was confirmed, the send is at least 60 minutes old, and your rate differs from MAYA's price by more than rounding. The day card then reads "Changed in Cloudbeds · $180.00", rules that had already moved the night are paused, and MAYA does not write over it. Read Rates changed in your property system.

Your change was written over for one of these reasons:

  • Your setting is MAYA's price wins. Then MAYA sends its own price over every change on a night it sent to, on purpose, and the Change Log lists each one. When MAYA's price wins explains it, and Settings is where to change it back.
  • Within the hour. You changed it less than 60 minutes after MAYA's send. MAYA reads your rates about once an hour, and again before re-sending a night it last sent to over an hour ago, so a change made inside that hour can be written over when MAYA's own price for the night changes.
  • A night MAYA had never sent to. Your rate there is read as the night's starting point, not as a manual price. Your rules work from it, and MAYA sends the result. This is also what happens to every rate you change while simulating.
  • A ThinkReservations night MAYA had not read back yet. A send to ThinkReservations counts as confirmed only once MAYA's hourly read finds it. Until then a different rate there is not read as your change.
  • A Cloudbeds send that never landed. When Cloudbeds never reported on a send, and 3 hours to a day later still has a different rate on that night, MAYA takes the send as not applied and sends its price again. A rate you set on that night in the meantime is written over.
  • Nearly every night differs by the same ratio. When 80% or more of the nights MAYA sent to (10 at least) differ from MAYA's price by one shared ratio (a system reporting prices with tax included, or a markup), MAYA reads that as your system's own arithmetic, not as edits, and keeps sending its own prices.

Why did MAYA price a night I closed in my system?

A night whose rate is 0 in your system, with no price typed in MAYA, is left unpriced. MAYA never opens a closed night at the floor.

The timing matters. MAYA reads your rates about once an hour and when your property's date changes. A night you close after MAYA has sent to it is read within the hour: its starting price becomes 0, the night is left unpriced, and any on it is cleared. Between your change and that read, MAYA's price may still be there. A night closed before MAYA ever sent to it is left unpriced from the first run.

Why was a night I set to 0 not sent?

MAYA does not send a price of 0 to any property system. A of 0 is a : no rule raises it, and the save confirmation says "Saved. MAYA doesn't send a price of 0 to Cloudbeds, so set the night to 0 there yourself." The change log carries an item that says the same until your system has the night at 0. Set it there yourself. Read Make a night free.

Why was a night I have no rate loaded for not sent?

A night your system has no rate for, and nobody has typed a price for in MAYA, is not priced and not sent, whatever its bookings paid. The day card reads "No rate in Cloudbeds for this night yet". Load a rate for it in your system and it is priced and sent within the hour, or type a price in MAYA, which is sent as typed. Read Nights your system has no rate for.

Why was a night 70 days out not sent?

MAYA prices and sends tonight and the next 395 nights, on your property's own calendar. A night 70 days out is not priced, refreshed or sent until it enters the window. A you type further out is saved now and sent when the night enters the window, and the confirmation says so: "Saved. It will be sent when the date enters the 396-day push window."

Every "Prices not reaching" sentence, and what to do

The item's second line names the cause, and the item itself says what to do. When your property system does not accept a price lists every one of those sentences with its meaning, the fix, and how MAYA retries.

A new price for tonight that never lands, while later nights go through, usually means your system and MAYA hold different time zones for your property. This one rarely shows in the change log. The time zone case has what to check.

Example: A minimum rate at The Harbour Inn

Sam sets a minimum of $120 on Deluxe in Cloudbeds. MAYA's floor for Deluxe is $110. On a slow Tuesday, "Last minute" cuts Deluxe from $140 to $119. The floor lets that through, and Cloudbeds refuses it. The change log shows at once: "Prices not reaching Cloudbeds", "Cloudbeds refused MAYA's price for Deluxe because it breaks a rate rule set in Cloudbeds, such as a minimum or maximum rate.", "1 night, 1 room type · Still happening", and "Check the rate limits for this room type in Cloudbeds."

Priya types $120 on that night on the Calendar tab, and it is sent. Cloudbeds takes it. The item then reads "Ended" with the time, because a new price replaced the refused one.

So that later cuts are not refused, Priya raises Deluxe's floor to $120 in its Floor box on the review. Only Deluxe changes. Answering the floor question again with $120 would fix Deluxe but move every other room type too: Standard's floor would rise from $80 and Suite's would fall from $180. Sam could instead lower the Cloudbeds minimum to $110 to match MAYA's floor.

Was this page helpful?

Not answered here? Email us. We aim to reply within one business day.