Reading Rate and Availability Push Logs Before You Call Support

Half of the tickets filed in a week answer themselves in the log, if the log is read in the right order.

Last updated: September 24, 2026

A push record tells you four things: what you sent, where it was addressed, when it went, and what came back. Read them in that order and most channel questions answer themselves. The mistake is reading only the last one. "Accepted" isn't "applied", and a log that looks clean at the bottom can be wrong three rows up. This guide walks the four columns, three signatures that point at a mapping error rather than a failed push, and the single signature where you really do need somebody else to look.

Key Takeaways

• Four columns carry the answer. What you sent, where it went, when it went, and what came back.
• Accepted isn't applied. An acknowledgement means the message arrived, not that the value landed where you meant.
• Three signatures mean mapping. A value you recognise from elsewhere, a night that reverts, and one unit behaving differently from its siblings.
• Capture before you write. A ticket with four values in it gets a useful first reply; one with a screenshot of a feeling doesn't.
• One signature needs the platform. When their own screens disagree with each other, it stops being your problem.

The four columns that matter in a push record, and what each one is telling you

Every channel calls these something different, and the labels move around during redesigns. So don't memorise names. Read the labels off your own screen, then sort what you see into four questions.

What you sent. The value itself, not the intent behind it. If the log shows a nightly rate of 140 and you meant 140 per night for two guests, the log isn't wrong — your mapping is. This column catches the largest share of "the channel is showing the wrong price" reports, because the number travelling is usually exactly the number you typed.

Where it was addressed. Channel, unit, and the date or date range. This is the column people skip, and it's the one that decides the diagnosis. If the address is right and the value is right, you're looking at a transport problem. If either is wrong, no amount of waiting will fix it.

When it went, and in what sequence. One timestamp tells you whether the push predates the change you're looking at. Two timestamps tell you about order, and order matters when two things write to one address. A rate change pushed at 09:00 and an availability change at 09:02, both accepted, don't tell you which one the channel is holding now.

What came back. An acknowledgement, a rejection, or a value. Read the value carefully, because this is where "accepted" gets misread as "applied". Some channels acknowledge receipt and then apply the value against an object you didn't aim at. The log looks green. The night is wrong.

Three log signatures that mean a mapping error rather than a failed push

A failed push is easy to recognise. It's rejected, it says so, and it repeats identically every time you retry. Nothing you change on your side makes it behave differently, and it usually affects a whole channel rather than one unit.

A mapping error doesn't look like that. It looks like this instead.

The value that came back is one you recognise from somewhere else. You pushed 140 for the sea-view unit and the log returns 120 — which is the figure sitting on the garden unit, or on a rate plan you retired in the spring. Nothing failed. The write went to an address that already held a value, and it either lost or overwrote. Recognising the number is the whole diagnosis.

A night reverts after being accepted. You close a date, the log acknowledges it, and two hours later the date is open again. That isn't a transport problem; it's two sources writing to one night, and yours isn't the one that wins. Look for the second writer before you look for the fault.

One unit behaves differently from its siblings. Three units on the same channel are fine and the fourth is wrong. A transport fault doesn't pick a unit. A mapping does, every time. The odd one out is your evidence, and it's also your suspect.

All three have the same test, and it takes five minutes. Pick one date, read what the channel's own guest-facing page shows for it, and compare that against the value in the log. Where the two disagree, you've found the row.

What to capture before you contact anyone, so the first reply is the useful one

A support conversation is only as good as the first message, and the first message is only as good as what you gathered before you typed it. Five things, and they're all cheap.

The four values. What you sent, the address, the timestamp, and what came back. Write them out as numbers and names, not as a description of what you think happened. "It said 140 but shows 120" beats "it isn't syncing" by about two days.

The test date and the test unit. One of each, named. A ticket about "the calendar" can't be answered; a ticket about unit 2 on 14 November can.

What the guest-facing page shows. Not what your side says it sent, and not what the extranet says in the admin view either — what a person shopping that date actually sees. Take the screenshot. It's the number everybody will be arguing about.

What you expected, in one sentence. It forces you to state the assumption you haven't checked yet. Half the time you'll answer your own ticket writing it.

Whether it repeats. Try once more, note whether the result is identical. Identical means deterministic, which points at configuration. Different each time points somewhere else entirely.

Gathering the first four is where four logins start to hurt. Availability and rates for Airbnb, Booking.com, Agoda and Trip.com sit on one grid at localsbnb.com, and each row shows the source rate and source status that channel is holding. So the value the channel has can be read off in one place, and your ticket can quote it rather than describe it.

The one signature that genuinely needs the platform, and how to describe it

Most of what looks like a platform problem isn't. One signature is.

Your push is acknowledged. The value in the log matches what you sent, addressed to the unit and date you meant. And the channel's own screens disagree with each other: the admin view on the extranet shows one figure, and the guest-facing page for that same date shows another. Nothing on your side can produce that. It's inside their house, and it's the one case where you should stop diagnosing and hand it over.

The second version of the same signature: every push to one channel is rejected, nothing on your side changed, and it worked last week. Credentials expire, permissions get revoked in a back office, and a connection gets downgraded without a message reaching you. Retrying won't help. Asking will.

How you describe it decides how fast it gets solved. One unit. One date. The value you sent. The value that came back. The value the guest-facing page shows. The last time it worked. Then one sentence on what you've already ruled out. That's a message somebody can act on in one pass, and it's the difference between a ticket that closes on Monday and one that's still open on Friday.

FAQ

The log says the push succeeded, but the channel still shows the old rate. What now?

Check the address column before anything else. A successful push to the wrong unit or the wrong rate plan is the most common cause, and it leaves a clean-looking log behind. Then read the guest-facing page for one date and compare.

How do I tell a mapping error from a genuine outage?

Scope and persistence. An outage is broad — a whole channel, or all of them — and it clears on its own. A mapping error is narrow, sticks to one unit or one plan, and survives every retry.

Should I re-push before I contact anyone?

Once, and note the result. One retry tells you whether the behaviour is deterministic, which is the single most useful fact in the first message. Twenty retries obscure it, and they make the log harder for anyone else to read.

Four columns, three signatures, one case that isn't yours. Read the address before you read the result, quote values rather than impressions, and name one unit and one date in every message you send. If you'd rather read what all four channels are holding without opening four logins, that grid lives at localsbnb.com.

---

Log layouts, column labels and push behaviour differ by platform, region and account type and change without notice; read every label off your own screen, and treat the current terms and settings in each platform's own admin as the authority.