The change log

What a pricing run is

A pricing run is one pass of MAYA over your property: it reads your bookings, runs every rule that is on against the nights that need it, and publishes a new price wherever one changed. The nights that need it are every night whose bookings changed since the last run and every night a change of yours reaches, and, in the first runs after midnight at your property, every night in the window (tonight and the next 395 nights), nearest first. A run where nothing needed pricing still counts as a run that changed nothing. When you are live, the changed prices are then sent to your property system. In simulation the run happens in full and the log fills in the same way, but nothing is sent, and the log words each change as what would have happened (Runs made in simulation).

Runs happen:

• About every five minutes, each time MAYA's scheduled read of your bookings succeeds. A read that fails prices nothing that time, and a property whose subscription has lapsed is skipped.
• Straight after you save or clear a manual price, on the nights you saved.
• Straight after you change a room type (saving ticks or unticks of Counts as a room, adding or clearing rooms out of service): the change asks for a run at once. Rooms out of service re-price their own nights. A room type setting re-prices every night in the window over that run and the next few, nearest first.

A run that finds nothing to change is counted into a quiet line between the runs that did. Show All Cycles shows those lines.

The two views

The button in the top right toggles between the two views:

• Show All Cycles is what the button says while you are in the default view. That view shows the runs that changed a price, every "Prices not reaching" problem, every answer you gave to a rule that kept adjusting, every item about rates changed in your property system, and every switch between simulation and live.
• Show Changes Only is what the button says once you have opened the full view. The full view adds the quiet lines. Each counts a stretch of runs in a row that changed nothing, with when the first and last of them ran, in small grey type: "Prices checked 47 times from Sep 24, 10:05 AM to 1:55 PM (4 min ago), nothing needed to change." A stretch of one reads "Prices checked once at Sep 24, 1:55 PM". The line under the oldest change shown starts "Just before that, prices were checked 12 times".

When no run has changed a price yet, the default view shows no runs at all, and no message says why. Any "Prices not reaching" problem and any answer you gave still show. Click Show All Cycles to see the quiet lines.

Under the heading sits the Your corrections panel, closed by default. It lists the past nights you have set aside as not a fair comparison. Setting a date aside explains it.

If the log cannot load you see "Couldn't load your price history." with a Try again link. Whatever had loaded before for the same property stays on screen. When you switch property the log starts empty, so nothing from the property you left shows under the new one's name, even if its log can't load.

A run entry

Each run is a box. The first line reads:

"Pricing run · Fri, Oct 2, 2026, 3:05 PM PDT (4 min ago)"

A run made while your property was simulating carries a small amber Simulation tag after that line.

The small ? at the end of the line opens the part of this page about runs (about runs made in simulation, for one tagged Simulation), in a panel beside the log. Every item in the log has one, the quiet lines too, each opening the part about its own kind of item (About these docs says how the panel works).

The time is shown in your browser's time zone, with the zone's abbreviation, so two people in different places see different clock times for the same run. Hover the line and the exact moment shows, to the second, on the same clock: "Oct 2, 2026, 3:05:12 PM PDT". The part in brackets says how long ago: "just now", "4 min ago", "2 hr ago", "yesterday", "3 days ago", up to 6 days. Older runs carry no bracket.

Under the first line comes the list of changes, the biggest moves first. One change is one night changed one way, however many room types it moved. A run that made more than 40 changes lists its 40 biggest and ends with a line counting the rest, such as "And 23 more changes in this run." A simulated run's line reads "And 23 more prices would have changed in this run."

A change, line by line

A change opens with a bold line naming the night, the room types and what changed in this run:

"Nov 13 · 7 room types · Warm-date bump +10%"

That is the stay night, how many room types the run changed this way (or the room type's name when it changed one), and what it was: a rule that fired with its amount, a change that came off ("Weekend nudge +10% came off"), "Cloudbeds' rate changed", "Price set by hand" or "Changed in Cloudbeds". A run that changed two things on the night names both: "Cloudbeds' rate changed, Warm-date bump +10%". In a simulated run the bold line starts "Simulation:" (Runs made in simulation).

Under the bold line, a short line says where the price went: "Sent to Cloudbeds.", "Waiting to be sent to Cloudbeds." and so on, or "Nothing was sent to Cloudbeds." in simulation. Where the price went lists them.

Each change starts from the price the night had just before this run, not from your own rate. So when "Hot-week surge" fires on a night an earlier run already raised from $150.00 to $165.00, it reads "Hot-week surge" raised this night 25%, from $165.00 to $206.25. The earlier raise is not told again. Rates you change in your property system explains where a night's own rate comes from.

Then come the sentences, in this order:

1. A price set by hand, typed or cleared. "Priya set the base rate to $180.00." or "The price set by hand was cleared." (Prices people set).
2. Your property system's rate. "Cloudbeds' rate went from $296.00 to $336.00, so the price moved to $420.00." Rules already on the night stay on it, so the price follows your rate.
3. What came off, and why. Cancellations meant "Warm-date bump" was no longer true, so its 10% raise came off. The next sentence gives the numbers the check found, such as: Of the 9 bookings it counted, 4 are still booked, where nights like it usually get about 5, and the rule needs a booking speed of at least faster than normal. A deleted rule reads "Weekend nudge" was deleted, so its 10% raise came off. A standard rule that stopped holding reads "Busy nights" stopped applying an earlier 10% raise here: this night no longer met its conditions, and it keeps saying so if you delete the rule later. One that stopped only because its booked so far vs usual part had too few similar nights reads "Weekend pace" stopped applying an earlier 10% raise here: there weren't enough similar nights to compare with. The other reasons are a price set by hand and a booking speed or pickup rule being edited. When two raises of one rule came off together, the line says how many: Cancellations meant "Hot-week surge" was no longer true, so two of its 25% raises came off, and the bold line ends "came off twice".
4. A standard rule that moved without firing. Edited with Apply price adjustments while it still holds, its change moves to the new amount: "Weekend nudge" was edited, so its raise went from 10% to 15%. Back on the price once a price set by hand is cleared: The 10% raise from "Busy nights" applies again. Neither is a new fire, so neither adds to the rule's count on the Rules tab.
5. Each rule that fired in this run, then why. "Warm-date bump" raised this night 10%, from $150.00 to $165.00. It was 82% full, past the 70% mark you set.
6. The limit, if one stepped in. That would have gone past your $300.00 ceiling for Standard, so it stopped there.
7. The move, when more than one thing changed: each is said on its own, then "That took this night from $150.00 to $206.25."
8. A fallback when nothing can be named: The price moved from $150.00 to $160.00.

Changes already on the price that this run left alone are named once, in small grey type under the sentences: "Warm-date bump's +10% still applies." They are never given this run's move.

Under each room type of a change, and under a change on one room type, Why this price? opens that night's price and the changes to it, newest first (Why this price?).

When the change moved several room types, Each room type under it opens the list: each room type with its own price before and after, such as "Loft $200.00 to $250.00", and "at your ceiling" where a limit held it. The sentences use the prices most of them share, and say so: "from $296.00 to $370.00 on 7 of 8 room types". When the room types' prices went different ways, each keeps its own line in the list, and the line under the bold line leads with the one that needs you: "Couldn't be sent to Cloudbeds for 2 of 7 room types."

A run that works a night out again and lands on the price it already had is not a change, however many rules are on the night, and gets no line.

Only one booking speed or pickup rule can fire on a night for one room type in one run. An earlier fire still on the price shows as a "still applies" note, never as part of this run's move.

Under the sentences, a change carries a Show the numbers button when the run read booking speed for that night, or judged a booked so far vs usual rule that changes that room type. With a booking speed rule that measures the whole property (every booking speed starter rule does), that is nearly every change, whichever rule made it, typed prices included. The numbers behind a change covers what it opens.

Runs made in simulation

While your property is in simulation MAYA runs every rule and writes every change here, but nothing is sent, so nothing in the log says a price changed. Each change says what would have happened instead:

• The run's first line carries the amber Simulation tag.
• The bold line starts "Simulation:": "Simulation: Nov 13 · Standard · Warm-date bump +10%". A change that came off reads "Simulation: Nov 13 · Standard · Weekend nudge +10% would have come off".
• The line under it reads "Nothing was sent to Cloudbeds." (or your system's name, or "your property system" with none connected). Once you are live it reads "Nothing was sent to Cloudbeds at the time."
• Each move says "would have": "Warm-date bump" would have raised this night 10%, from $150.00 to $165.00. A change still on the price: "Warm-date bump's +10% would still apply."
• What came off: Cancellations meant "Warm-date bump" was no longer true, so its 10% raise would have come off. "Busy nights" would have stopped applying an earlier 10% raise here: this night no longer met its conditions.
• A limit: That would have gone past your $300.00 ceiling for Standard, so it would have stopped there.
• A night moved by more than one thing, or by something coming off: That would have taken this night from $165.00 to $150.00. With nothing else to say: The price would have moved from $150.00 to $160.00.
• A price typed in MAYA: "Priya typed a price of $180.00."

Problems sending prices don't show in simulation, since nothing is sent, with one exception: on ThinkReservations, a room type MAYA can find no rate type for sits at the top as "No rate to price from in Think Reservations", because it isn't priced at all. Read the rate type causes.

What the run saw stays as it was: "It was 82% full, past the 70% mark you set." is true in either mode. So is your own rate in your system changing, "Cloudbeds' rate went from $150.00 to $160.00, so the price would have moved to $160.00.", a rule being deleted, and "The price set by hand was cleared."

The label follows the moment of the run, not the mode you are in now. Once you go live, the runs from before keep their Simulation tag and their "would have" words, and new runs read as live.

Once you go live, the first live cycles send every night's price, including prices worked out in simulation (Going live). So a simulated change's line then reads "Nothing was sent to Cloudbeds at the time.", and when its run was the last to price that night and the night still has its price, a second line says what became of it, from MAYA's record of its sends:

A simulated change whose price a later run replaced gets no second line, and nor does one on Mews, where nothing is sent.

MAYA keeps a record of every switch between simulation and live, and reads each run's mode from it. For runs from before it kept that record, it works the mode out from what it had on file: a property that had never been live has every run marked as simulated. Where it cannot tell, for example a run from before mid-September 2026 on a property that was already live then, the run reads as a live one always has, with no line about sending.

Where the price went

On a live property, the line under a change's bold line says what became of its price, as MAYA's own record of its sends shows it:

MAYA keeps one record per night and room type: its latest send. So a change gets one of the live lines only when its run was the last to price that night and room type, and the night's price is still its price. That is checked against MAYA's own records, not against what the log has on screen: a later run counts even when it is on a newer page, or its change for that night is one of those only counted under "And 23 more changes in this run." An older change, whose price a later run replaced, has no line at all, because MAYA can no longer say whether that price went. Nor does a night already over that was never sent: nothing will send it now.

"Waiting to be sent" is only said while MAYA can send the price. When your property is back in simulation, MAYA's work is paused over your subscription, the connection reads Disconnected, or the night is beyond the 396-night window, an unsent price gets no line. Everyone on the property sees these lines, whatever their role.

The sentences, by kind of rule

Every "why" sentence is built from your own rule: the mark you typed, the room types it measures, and the numbers the run saw. The shapes below use The Harbour Inn's rules.

Occupancy and booking window

These two share one sentence, because you set them as one condition.

Read "past" as "on the far side of the mark in the direction you asked for". A booking window counts down, so a night 2 days out is past a 3-day mark, not short of it.

Pickup count

"9 room nights booked over the last 3 days, past the 4-room-night mark you set." The days are the rule's lookback, counted from the day of the change: "over the last 30 days" for a 30-day rule, "that day" for a 1-day rule. A rule set to Less than counts full days only and reads "over the last 3 full days" and "under the 4-room-night mark". When more room nights cancelled than were booked, it reads "2 more room nights cancelled than booked over the last 7 full days". When the rule counted only from the newest change on the night by itself or a stronger rule, the sentence says so instead of naming the window: "6 room nights booked since this rule or a stronger one's latest raise still on this night, past the 4-room-night mark you set." When the rule measures other room types than the ones it changes, it names them: "9 room nights booked in Standard and Deluxe over the last 3 days, ...". Without a count: "Room nights booked over the last 3 days came in past the 4-room-night mark you set."

A room night is one room for one night, so a 3-room booking for one night reads as 3 here. Pickup count has the detail.

A pickup rule with Pickup measures set to Revenue (currency) fires on the money booked, but its sentence still shows the room nights, with your amount as the mark. A rule set at 500 reads "9 room nights booked over the last 3 days, past the 500 revenue mark you set." The 500 is the amount you typed, in your property's currency, and the 9 is the room nights gained in those days.

Booking speed

The sentence opens with the level the rule is written for, then the count, then what a night like this usually has:

"this past week" becomes "this past day" or "this past month" to match the rule's Measured over setting. A rule that cuts counts full days only, so its sentence reads "in the week up to yesterday" and "usually gets in those days". Then:

"Bookings came in faster than normal this past week: 9, against the 5 a night like this usually has by now."

The count can read "none" or, after cancellations, "more cancelled than booked". When similar nights usually have fewer than 1 booking by that point it reads "where a night like this usually has almost none by now".

After the night has already been raised or cut. Once the rule, or a stronger booking speed or pickup rule that moves the price the same way, has changed a night, the rule counts only the bookings made since the newest such change still on that night. A standard rule's change never restarts the count. A stronger rule's change that going live from your current rates took off still counts as that starting point, though it is no longer on the price (Counting after a change). The log cannot say which of those rules made the change, so the sentence names both and the days counted. For a raise, the day of the raise is the first day:

"Bookings came in much faster than normal in the 4 days since this rule or a stronger one's latest raise still on this night: 12, against the 5 a night like this usually gets in a whole week."

"in a whole week" is for a rule that raises on a fast pace: those bookings alone had to beat a whole window of a similar night. Any other rule reads "usually gets in those days". When only the day of the raise has been counted so far, it reads "later on the day of this rule or a stronger one's latest raise still on this night" and, for any other rule, "usually gets in a day". After a cut the count starts on the day after it, in full days: "in the 3 full days after this rule or a stronger one's latest cut still on this night". After a rule acts explains why the count restarts.

When some of the bookings counted were a group your system links, or bookings made together (only while Count bookings made together as one is on in Settings), a sentence after it says how they were counted: "10 reservations in one Cloudbeds group counted as one booking." or "4 bookings made together for the same dates were counted as one." With Count a group as up to above 1 in Settings, it says how many: "4 bookings made together for the same dates were counted as 3." Read What is counted.

When the rule measures other room types than the ones it changes, the subject changes: "Standard and Deluxe bookings came in faster than normal this past week: ...". A rule that measures and changes the same room types reads "Bookings", with no names, even when those are only some of your room types. Show the numbers names the room types whenever a rule measures only some of them.

Booked so far vs usual

The rooms booked of the rooms to sell, the days to go, what similar nights usually had by then, and the gap in rooms, against your percent:

• "It had 12 of its 20 rooms booked with 30 days to go, where similar nights usually had 7 by then: 5 more, reaching the 25% mark you set."
• "Standard and Deluxe had 3 of their 20 rooms booked with 10 days to go, where similar nights usually had 7.5 by then: 4.5 fewer, reaching the 20% mark you set.", for Behind usual by at least 20 on a rule that measures other room types than it changes.

"By then" is the point the night was read at: the entry stays the same however long after you read it. The usual is to 0.1 of a room, as the rule judged it, and reads "none" when similar nights had nothing booked. Booked so far vs usual has the detail.

Rooms left to sell

Rooms left to sell has the detail.

Recent bookings

Always the whole property's, so the sentence says "across the property":

• "22 bookings came in across the property in the 7 days up to yesterday, reaching the 20-booking mark you set."
• "No bookings came in across the property yesterday, under the 3-booking mark you set."
• When a group your property system links counted as one booking: "Across the property, 10 reservations in one Cloudbeds group counted as one booking."

Recent bookings (advanced) has the detail.

Current rate and average rate booked

Amounts are in your property's currency.

• "Its current rate was $142.00, under the $150.00 mark you set."
• "The average current rate of the 3 room types it measures was $165.00, past the $160.00 mark you set."
• "The 4 rooms booked averaged $188.00, past the $180.00 mark you set."
• "The room booked averaged $210.00, past the $180.00 mark you set."

Read Current rate and Average rate booked, ADR (advanced).

A room type left out

When an occupancy rule measured room types that do not count as rooms, those were left out of the figure, and one more sentence says so: "That 82% leaves out Meeting Room." A rooms left or booked so far vs usual rule says it about its count: "That count leaves out Pickleball Court."

The same rule twice on one night

A booking speed or pickup rule can act on the same night again after its wait. Each fire is a change of its own, in the run that made it: "Hot-week surge" raised this night 25%, from $206.25 to $257.81, with "Hot-week surge's +25% still applies." under it for the first fire.

Prices people set

A manual price shows as its own change, led by a sentence naming who typed it:

"Priya set the base rate to $180.00."

The name is the person's profile name in MAYA. If no name is stored it reads "A manager". A price our staff typed for you reads "MAYA support set the base rate to $180.00." A rate you changed in your property system on a night MAYA had sent to names no person: "The base rate was changed in Cloudbeds to $180.00." (or "in Think Reservations").

Its bold line reads "Nov 13 · Standard · Price set by hand" ("Changed in Cloudbeds" for a rate changed there). When a rule's change was already on the night, your price takes it off (a standard rule's is paused), and the bold line names that too: "Nov 13 · Standard · Price set by hand, Warm-date bump +10% came off". The lead is then followed by ""Warm-date bump" stopped applying an earlier 10% raise here: this night's price was set by hand." and the move, "That took this night from $165.00 to $180.00." If a rule later fires on top of your price, that is a change of its own, from your price.

A price typed while your property is simulating reads "Priya typed a price of $180.00.", under the bold line "Simulation: Nov 13 · Standard · Price set by hand" and the line "Nothing was sent to Cloudbeds."

Rules you change or delete

Each entry keeps every rule as its run had it: the rule's name, the marks you had set, the room types it measured and the amount it applied. So when you edit, rename or delete a rule later, its older entries still say what happened then.

Deleting a rule takes its changes off, and the next run that prices the night says so: "Weekend nudge" was deleted, so its 10% raise came off. That took this night from $462.00 to $420.00.

Entries from before October 2026 did not keep the rule, so they borrow it as it is now:

• If you have only renamed the rule, or switched it off and on, the entry reads as usual, under its name now.
• If you have changed anything else, such as its amount, its condition, its room types or its dates, the entry shows the amount the run applied and the numbers the run saw, with no mark beside them, then "The rule has been edited since.": "It was 82% full. The rule has been edited since." Your marks at the time are not on record. A change with no numbers on record shows no reason at all.
• If MAYA cannot tell which settings an older booking speed or pickup change was made under, it shows the numbers only, without that last sentence.
• If you have deleted the rule, its moves read "Pricing rule", with no sentence saying why. Its change coming off reads "A rule was deleted, so its change came off."

Your answers

When you answer the Rules that keep adjusting banner, the answer is logged as its own item headed "Your answer", with the time, saying who answered and what they chose for which nights. Your answers in the change log lists every wording.

Going live and back

When someone on your property switches it between simulation and live, the switch is its own item, where it happened among the runs:

• Went live · Fri, Oct 2, 2026, 3:12 PM PDT: "Sam took pricing live. From the next cycle, MAYA sends its prices to Cloudbeds."
• Back to simulation · ...: "Sam switched pricing back to simulation. MAYA stopped sending prices to Cloudbeds."

It marks where the log's wording changes: runs before a go-live say what would have happened, runs after it say where each price went. It says what going live does, not that a given price went out: each change's own line says that. A person MAYA has no name for reads "A manager". On Mews it reads "Sam took pricing live. MAYA doesn't send prices to Mews yet, so nothing goes to it." A switch our staff made for you shows as a change by MAYA support instead (below), and the first mode a new property starts in is not an item.

A go-live that started from your current rates says so (Going live):

• "Sam took pricing live, starting from your Cloudbeds rates. Your rules act on what newly becomes true."
• "Sam took pricing live, starting some nights from your Cloudbeds rates. From the next cycle, MAYA sends its prices to Cloudbeds." (chosen by rule and night)

Each change it took off is a line of the first live runs, headed such as "Nov 12 · Garden Room · Weekend surge +10% came off when you went live". Its two sentences:

• "Weekend surge" stopped applying its 10% raise here: you went live starting from your Cloudbeds rates.
• $220.00 was MAYA's simulated price and was never sent to Cloudbeds. The price is now $200.00.

The price before was MAYA's in simulation, so the line never reads as a price that went down in your system.

Changes by MAYA support

When our staff change something on your property for you, each save is logged as its own item headed "Changed by MAYA support · Fri, Oct 2, 2026, 3:12 PM PDT", with one line under it saying what changed:

• Changed by MAYA support: Took pricing live.
• Changed by MAYA support: Changed the pricing rule "Hot-week surge": action_value from 10 to 15.
• Changed by MAYA support: Changed the pricing rule "Hot-week surge": action_value from 10 to 15, 12 days.
• Changed by MAYA support: Removed a team member.

One item per save, however many things it changed. A rule saved together with nights it covers, such as the days it leaves as they are or the days it waited on after going live from your current rates that an Apply ends, is one line: the rule's own change, then how many days. When our staff take your property live from your current rates, the days your rules wait on are counted on the same line as the switch. A save of nights alone says what kind of thing changed and how many days, as in "Changed a base rate, 2 days." Deleting a rule is one line too, with how many days a standard rule had changed. A booking speed or pickup rule's changes come off just before it and are an item of their own, as in "Removed a pickup event, 3 days." Items sit where they happened among the runs, at most 20 within the span of the runs on screen. Our staff can only make these changes in a time-limited support mode that records every one, as Can our staff see your property? explains.

Rates changed in your property system

On Cloudbeds and ThinkReservations, a rate changed or removed in your system on a night MAYA had sent a price to can bring items of its own, headed "Changed in Cloudbeds" (or "Changed in Think Reservations") with the time MAYA read the change. Which ones depends on your setting, in Settings under your system's name.

With MAYA's price wins, each night and room type MAYA sends its price to again is one item, naming the night, the room type, your system's rate and MAYA's price. MAYA writes the item when it reads the change, moments before that run sends its price, so the item says the price went only once MAYA's record of its sends shows it:

• Fri, Nov 13, Standard: changed in Cloudbeds to $175.00. MAYA sent its price, $165.00, again.
• Fri, Nov 13, Standard: the rate was removed in Cloudbeds. MAYA sent its price, $165.00, again.
• Fri, Nov 13, Standard: changed in Think Reservations to $175.00. MAYA sent its price, $165.00, again. Accepted by Think Reservations, checking. (Until MAYA's hourly read finds the price there.)
• Fri, Nov 13, Standard: changed in Cloudbeds to $175.00. MAYA's price, $165.00, is waiting to be sent again. (Until the run sends it, normally moments later.)
• ... MAYA's price, $165.00, couldn't be sent again. (MAYA stopped trying.)
• ... MAYA's price, $165.00, was held back, not sent.
• ... MAYA's price, $165.00, was due to go out again. (The item doesn't say how the send went, for example because a later price or change has replaced it. On a page Older added, an item says only that MAYA sent its price, or this.)

The warning that something other than MAYA seems to be changing rates comes with Keep the change as your price, in an amber box: "Something other than MAYA seems to be changing rates in Cloudbeds: 34 rates changed in the last 7 days on nights MAYA had sent a price to. Each change is kept as your price, so MAYA isn't pricing those nights. If you use another pricing tool, turn on "MAYA's price wins"." Its Open the setting button opens Settings at your system's section. Once that setting is on, the button is gone, and the item's last two sentences become one: "Each change was kept as your price until "MAYA's price wins" was turned on." Turning it on handed those nights back to MAYA.

These items sit where they happened among the runs, within the span of the runs shown. Every warning is listed, and the newest 50 of MAYA's overwrites. One line under them counts the overwrites left out, without checking each one: "And 12 more times MAYA's price was due to go out again over a rate changed in Cloudbeds." A change you keep as your price is not an item of its own: it shows in the next run as "The base rate was changed in Cloudbeds to $180.00." (see Prices people set). Rates you change in your property system explains when each happens.

Your property changed in Cloudbeds

On Cloudbeds, MAYA's daily read of your property can bring items of its own, under the same "Changed in Cloudbeds" heading with the time MAYA read the change. Each names the room type in full, or the time zone or currency before and after:

• Deluxe is no longer in Cloudbeds. MAYA stopped pricing it, and its rooms no longer count toward your occupancy or your bill.
• Deluxe is back in Cloudbeds. MAYA prices it again, and its rooms count toward your occupancy and your bill.
• Your time zone changed from America/Denver to America/Chicago, to match Cloudbeds. Tonight and every rule's dates follow it.
• Your currency changed from USD to CAD, to match Cloudbeds. Amounts in MAYA are now in CAD; nothing was converted. (Only while your property is in simulation.)

These sit where they happened among the runs, within the span of the runs shown. Room types and rooms out of service and Time, weekends, currency and holidays have the detail.

Prices not reaching your property system

When you are live and a price cannot be delivered, the log carries an amber item headed "Prices not reaching Cloudbeds" (or "Think Reservations"). How soon it appears depends on the cause:

• A problem that needs you, such as lost access or a price your system refuses: at once.
• Your system cannot find the rate MAYA writes to: after one more try. MAYA reads your list of rates again and sends once more on the next run, about five minutes later. If the rate is still missing, the item appears then.
• A problem that often clears on its own, such as your system not answering, asking MAYA to slow down or not confirming a send: only once a night has failed at least 5 times over at least 2 hours.

A few holds MAYA applies itself never appear here.

While the problem lasts it sits at the very top, above every run. Once it ends it drops to where it ended: among the runs shown when that moment is within them, or further down once Older has added the runs around it. Mews never has these items, because nothing is sent to Mews.

The item names the cause in one sentence, counts the nights and room types affected, says "Still happening" or when it was resolved, and tells you what to do when there is something to do. Show 12 tries opens the attempts behind it. When your property system does not accept a price walks through every cause.

How far back the log goes

How far back 10 changes reach depends on your property: on a busy day perhaps an hour, on a quiet week several days. Older, under the last item, adds the next 10 runs that changed a price below them, with the quiet lines between them and everything else that happened in that stretch: problems that ended, your answers, changes by MAYA support and rates changed in your system. A problem still going on stays at the top only. Click it again for the 10 before those, and so on. While a page loads the button reads "Loading…"; if it cannot load, "Couldn't load older history." shows beside it, and clicking it tries again. Once the oldest run kept is on screen the button goes, and "Nothing older. History is kept for 90 days." shows in its place. Show Changes Only and Show All Cycles apply to every page shown. Opening the tab again, or switching property, starts again from the newest 10.

Moves the log does not list

The log lists every price move a run made:

• A price going back down, or up, because something came off: the rule stopped holding (for "Busy nights", the night falls to 80% full or less), cancellations took its change off, you deleted it, or you cleared a price you set. The entry names what came off and ends "That took this night from $165.00 to $150.00."
• A price that moves because your own rate moved reads "Cloudbeds' rate went from $150.00 to $160.00, so the price moved to $176.00." On Cloudbeds and ThinkReservations that is a new rate MAYA reads from your system (about once an hour). On Mews, it is a price someone typed.

What is left out: moves past the 40 biggest of a run, which are only counted ("And 23 more changes in this run."), a night arriving in the 396-night window with nothing on it, and a run that worked a night out again to the price it already had. To see where a night stands now, open the Calendar tab.

Finding an older change

The log opens on the 10 most recent runs that changed a price, so on a busy day a change from this morning may already be below them. Click Older at the bottom until it shows: each click adds the 10 runs before. For one night and room type, Why this price? is quicker (below). MAYA keeps every run and the detail behind each change for 90 days: the night's starting price and the price published, which rules acted, and the numbers each one saw. After 90 days the detail is gone, and the log ends there. If you cannot find a change, email us with the room type, the night and roughly when the price moved, and we can look it up for you within those 90 days.

To see every time one rule acted, click its count in the Fired column on the Rules tab. Read The fire log.

The Calendar tab shows each night's current price, with a badge while a price typed in MAYA or changed in your system is in place. To see the changes a night has had, open Why this price? under a room type's price in the day detail: it lists that night's changes newest first, back through the 90 days (Find out why a price changed). To keep your own record past that, copy the entries you care about.

The rough estimate

At the bottom of the log, under Older, one line adds up what MAYA's prices added, from bookings already made:

"Rough estimate since Sep 21: you've added about $966 with MAYA's prices."

While MAYA's prices aren't being sent to your property system (in simulation, on Mews, or while sending to your system is switched off), it says what you would have added: "Rough estimate since Sep 21: you would have added about $966 with MAYA's prices." A property that has been both says both: "you added about $1,210 with MAYA's prices while live, and would have added about $1,130 in simulation." When some of the time prices weren't sent was while live (on Mews, or with sending switched off), it reads "you added about $1,210 with MAYA's prices while they were sent, and would have added about $1,130 while they weren't." On a property whose prices are being sent now, an amount that would have been added on its own ends "with MAYA's prices in simulation." or, after time live with prices not sent, "with MAYA's prices while they weren't sent." The date is the first day with an amount counted, with the year when it isn't this year. Amounts are whole, in your property's currency. Until something counts, the line reads "Rough estimate: you haven't added anything with MAYA's prices yet." While prices aren't being sent, it reads "you wouldn't have added anything".

The ? at the end of the line opens "How it's worked out": the method below, in short. The line comes in after the log, reading "Rough estimate: working it out…" while it does. If it can't be worked out it reads "Couldn't work out the rough estimate." with Try again.

It counts bookings already made, never nights still to sell, so it is not a forecast. Nobody can know what would have happened at your own rate, so it is an estimate, worked out the same way live and in simulation, in two parts.

Raised nights. A booking made while a rule had MAYA's price above your rate for that night and room type adds the raise: MAYA's price less your rate, both as they were in the run of the latest raise still on the price when the booking came in. If a rule put MAYA's price at $240 on your $200 rate, each room booked for that night adds $40. What the guest paid doesn't enter into it, so a price you copy from MAYA into your property system by hand still counts as the raise. A booking counts when it reaches MAYA the same day it was made, by your property's clock (or in the half hour after that midnight), and one made days after the raise counts too while the raise is still on the price. A price you set for the night yourself replaces the raise while it is set. Free stays don't count, and on Cloudbeds and ThinkReservations, which mark group bookings, neither do groups.

Cut nights. While MAYA's price was below your rate, each booking beyond the night's usual pace adds what an average booking of that stretch paid. It is worked out room type by room type. The usual pace is the one booking speed rules use for that room type: what similar nights got over the same days before arrival (Booking speed in detail (advanced)). Bookings are counted in each room type on its own: a reservation counts once in each room type it booked, however many rooms of that type it has, and its amount is its rooms of that type for the night. A group your property system links counts once, once MAYA has read your booking history with the links. The Bookings settings change how booking speed counts, not this count. A night with nothing to compare with adds nothing. Only active room types ticked Counts as a room are looked at. The stretch runs from the moment the cut began to the day before it came off (yesterday, while it is still on), and no later than the arrival day.

Nothing is subtracted. A cut's lower price is never taken off, so neither part goes below zero. A booking that is cancelled drops out.

Added, or would have added. An amount counts as added when MAYA's prices were being sent to your property system at the time, whether or not your system accepted that night's price. It counts as would have added when they weren't: in simulation, on Mews (MAYA doesn't send prices to Mews yet), or while MAYA had sending to your system switched off. The ? says which applied. Time before MAYA has a record of whether you were live or in simulation doesn't count, and the ? names the date it starts from.

When it changes. A raised night's amount is kept the moment its booking reaches MAYA, so it stays after the log's 90 days. A cut night is worked out again on each fresh read while its bookings can still arrive, and kept once the night is over and its bookings are all in. The line is read afresh when you open the log, at most once every 10 minutes; reloading the page reads it afresh straight away. So the cut part can move while those nights are ahead.

The line gives totals only: nothing breaks it down by night, room type, rule or booking. Everyone who can read the change log sees it.

Money and names

The sentences and the prices under each change follow your property's currency: "$" for US dollars, "€" for euros, "£" for pounds, and the three-letter code in front of the amount for any other currency. The calendar and the Rate Simulator use the same sign.

Everyone on the property can read the change log, whatever their role.

Something to try