Channel Connection Troubleshooting: The Order of Checks That Saves Time

Most connection faults are found in the wrong place first. Working a fixed order turns a two-hour hunt into a ten-minute check.

Last updated: September 26, 2026

A rate that won't appear on a connected channel feels like a mystery, so hosts start clicking. Four tabs later, nothing has been ruled out and the original question is still open. The fault is usually in one of three places, and they're not equally likely — which is exactly why the order you check them in decides how long this takes.

Key Takeaways

• Read before you click. Connection state and the last successful push tell you whether the problem is one-sided or shared.
• Mapping is where faults live. A mismatch between a room type and a rate plan explains most of what looks like a sync failure.
• The extranet comes last. It's the slowest place to look and rarely where the fault started.
• One listing, one variable. Change a single thing, then re-check, or you lose the ability to tell what fixed it.
• Write down what you found. A five-line log turns the next fault into a two-minute check.

Start with what you can see: connection state and last successful push

Before changing anything, read the two indicators that are already in front of you. The first is the connection state for that specific channel. The second is when the last successful push happened for that specific listing.

Those two readings sort the problem into one of two families. If the connection state shows a problem, you're dealing with a link that needs re-authorising or a credential that has lapsed, and nothing downstream is worth checking until that's resolved. If the connection reads healthy but the push hasn't landed for this listing, you're looking at a mapping or content problem rather than a link problem.

The distinction matters because the fixes live in different screens. Hosts who skip this step tend to start in the mapping screen when the real problem is a stale connection, and then conclude the mapping is broken because changing it didn't help.

One caution belongs here. A channel showing as connected doesn't mean every listing on it is pushing. Connection is channel-level; the push is listing-level. Where you have several properties on one channel, confirm that the fault follows the listing rather than the channel, because that single observation usually halves the search.

Then the mapping screen, which is where the fault usually lives

If the connection is healthy, go straight to the mapping screen, and expect to find the answer there. Mapping is where a listing's room types and rate plans are tied to the equivalents on the channel, and it's the most common origin of what hosts describe as a sync failure.

Three mismatches account for most of it. A room type that exists in your system but was never mapped to anything on the channel, so changes have nowhere to land. A rate plan mapped to the wrong channel plan, so the price moves but it moves onto a different product. And a listing added on the channel side that was never mapped back, which is the usual explanation for a new property that looks connected but stays empty.

Work through it in a fixed sequence rather than scanning. Confirm the listing itself is mapped. Then each room type. Then each rate plan, checking that the plan you're editing is the plan the channel is displaying. A rate that appears not to update is frequently a second plan doing the updating while you watch the first.

The calendar usually settles which of these it is. LOCALSBNB shows the source price and source status from each directly connected channel — Airbnb, Booking.com, Agoda and Trip.com — so you can compare what your side intends to send against what the channel side is actually holding, without leaving the screen. A gap between those two columns localises the fault immediately.

Two habits keep this step quick. Change one mapping at a time and re-check before moving on, because a batch of edits tells you nothing about which one worked. And note the listing's internal reference before you start, so you can find it again in the channel's own system without guessing at names.

Only then the channel's own extranet, and why it comes last

If the connection reads healthy and the mapping is clean, the channel's own extranet is the next stop — but it should be the last, for three reasons.

It's the slowest place to look. Signing in, navigating to the right listing and finding the right rate plan takes longer than either of the first two checks combined. Second, it's the least likely to be the source. Channels hold what they were sent, and a channel that holds nothing was usually sent nothing. Third, changes there are the hardest to undo cleanly, which makes it the wrong place to start experimenting.

When you do go in, go with a specific question rather than a general one. Not "is the listing there?" but "does this rate plan exist, and what value does it currently show?" Compare that value against the source price on your own calendar. If the two match, the fault is in what you're sending. If they differ, the channel has received something other than what your side believes it sent, and that's a support conversation rather than a settings one.

Two structural details are worth understanding before you file anything. Directly connected channels and calendar-feed channels behave differently — a direct connection carries structured updates in both directions, while a feed carries a limited set of fields one way. If part of your setup runs on a feed, some changes will never propagate, and no amount of re-checking will change that.

Also confirm what the channel itself expects from the listing before assuming a fault. A listing that's incomplete on the channel side can accept a connection and still not display rates, which reads as a sync problem and isn't one.

One habit makes this last step shorter. Compare what the channel currently holds against the source status your own calendar shows for that channel before you message support — both sides are visible on localsbnb.com, which turns a vague report into a specific one.

What to record so the next fault is faster

The difference between a host who spends ten minutes on the next fault and one who spends two hours is usually a log. It doesn't need to be elaborate — five lines per incident is enough.

Record the date and time you noticed it. The channel and the listing reference. Which layer turned out to be at fault. What you changed. And what confirmed the fix. That last line is the one people skip, and it's the one that stops the same fault coming back unnoticed.

After three or four entries, patterns show up that no single incident reveals. One channel producing most of the mapping problems. One listing whose room types keep drifting. A particular rate plan that needs re-checking after every seasonal change. Those patterns are worth acting on, because they predict the next fault rather than just recording the last one.

Keep the log somewhere you'll find it under pressure, and keep it separate from the listing's public content. A running note beside the connection settings is more useful than a tidy document nobody opens.

FAQ

The connection shows as healthy but nothing updates. Where do I look?

The mapping screen. A healthy channel-level connection with a listing that isn't updating usually means a room type or rate plan isn't mapped, or is mapped to the wrong counterpart. Check the listing first, then room types, then rate plans.

A rate change showed on one channel and not another. Why?

Each channel is mapped separately, so one can be correct while another points at a different plan. Compare the source price your calendar shows for each channel, then check the mapping for whichever one is out of step.

Should I disconnect and reconnect to force a fix?

Not as a first move. Reconnecting clears the evidence you'd need to find the cause, and if the fault is a mapping mismatch it will come straight back. Reconnect only after confirming the connection state itself is the problem.

Work the order once and it becomes reflex: read the state, check the mapping, and only then open the channel's own system. The point isn't that any single step is clever. It's that a fixed sequence rules things out instead of adding tabs. Hosts who manage several channels from one calendar at localsbnb.com tend to keep the same order for every incident, which is what makes the log useful rather than decorative.

---

This article is general guidance for hosts; features, channel behaviour and platform terms differ and change, and the current documentation and terms for each platform prevail.