A Twenty-Minute Monthly Channel Health Check

Channels do not usually break loudly. They drift, and the drift is only visible if you go looking for it on a schedule.

Last updated: September 25, 2026

Twenty minutes, once a month, in a fixed order. That's the whole proposal. Most channel faults don't announce themselves — a connection stays green while a rate plan quietly stops being sellable, or a room type gets renamed on one side and orphans the plan attached to it. Nothing errors. Nothing alerts. You find out when two guests arrive for the same night.

This guide splits those twenty minutes into four stages with a job each, and tells you what to write down at the end. Dashboards and the fields they show differ by platform and change between releases, so treat the stages as the durable part and confirm the specifics against your own screens.

Key Takeaways

• Drift doesn't alert. A green connection can be pushing to a plan nobody's selling.
• Four stages, one job each. Connection, parity, mapping, then the log.
• Sample three dates. Near, mid and far — a fault that only exists in one window is invisible on tonight's rate.
• Renames orphan plans. The mapping screen is where a decision you made in March breaks in September.
• Unlogged checks are worthless. Next month needs a baseline, and memory isn't one.

Minute 0–5: connection state, last successful push and anything sitting in an error queue

Start with the boring question: is each channel still connected? Not "did it connect once" — is it connected now, and did the most recent push go through? That second half is the part people skip. A connection can be authenticated and current while its last several pushes failed for a reason that has nothing to do with credentials.

Then open the error queue, if your setup has one, and read it rather than counting it. Failed pushes sit there. They don't retry forever, and they don't usually raise anything you'll notice. A queue you never open is how a rate stays wrong for weeks without anybody having decided it should be.

While you're in there, check the thing that isn't an error: a channel that's connected and pushing, but pushing to a rate plan you retired. That's not a failure in any log. It's a successful write to the wrong address, and it's the most common finding in this stage.

One more thing worth a glance while you're in there: whether the channel list is what you think it is. Hosts add a channel, test it, and leave it half-configured for a season. A half-configured channel isn't an error, and it's worse than an absent one, because it looks finished.

Five minutes, and you'll usually have found either nothing or one thing. Both are good outcomes if they're recorded.

Minute 5–12: rate and availability parity between what you set and what the channel shows

Parity is a comparison, not a feeling. Pick three dates and check all three on every channel: one seven to ten days out, one around six weeks out, and one three months out. Near, mid, far.

Three dates rather than one because faults are date-bound. A seasonal rate plan that hasn't started yet, a promotion with an end date, a minimum stay that only applies to weekends — none of those show up on tonight's rate, and all of them show up on a guest's screen eventually. One date tells you the pipe works. Three tell you the calendar's right.

For each date, check three things. Does the channel show the rate you set? Is the night open or closed in both places? And does any restriction differ — a minimum stay on one side that isn't on the other is a night you'll sell at the wrong length, which is its own kind of wrong.

Availability deserves a second look too, because open and closed isn't the whole field. A night can be open on both sides and still not sellable, if a minimum stay straddles it or if it's the single night left between two bookings that no arrival rule will fill. Those gap nights lose money without ever showing a mismatch — both sides agree, and the night still goes unsold.

Don't fix everything you find in this stage. Note it. The point of minutes 5–12 is to find out whether your calendar and the channel agree, and that answer is worth more than a partial repair done in a hurry.

Minute 12–17: the mapping screen, where a renamed room type quietly orphans a rate plan

This is the stage that catches the expensive one. A rate plan is attached to a room type by name or by identifier. Rename the room type on your side, or rebuild it, and the attachment can survive as a pointer to something that no longer exists. The plan keeps its rate. It just isn't sellable, because the thing it's selling has gone.

Walk the mapping screen looking for four shapes. A rate plan with no channel attached. A room type on your side with no counterpart on the channel. A room type on the channel that isn't in your system. And two rate plans mapped to the same rate type — which looks efficient and behaves badly, because one of them is now carrying conditions written for the other.

The reason this stage earns its five minutes is the failure mode it prevents. A unit that's open on two channels with a calendar only one of them is reading is how a double booking happens. Not through a dramatic outage — through a mapping nobody re-read after a rename.

Where a channel exposes what it's holding, read it there rather than trusting your own side. Airbnb, Booking.com, Agoda and Trip.com each show the rate and the status they're holding on one calendar at localsbnb.com, so the comparison is made against what's actually out there rather than against what you last sent.

Minute 17–20: write it down, so next month compares against something

Three lines, in one place, and you're done. The date you ran it. The three dates you sampled and what each channel showed. Anything you fixed, and anything you deliberately deferred.

That's it. Not a report — a baseline. Drift is only legible against a previous reading, and a note saying "12 November, far date wrong on one channel, corrected" tells next month's check exactly where to look first. Without it, every month is a fresh investigation with no memory.

If the same fault turns up three months running, it isn't a monthly problem any more. It's structural — usually a mapping that gets rebuilt by hand each time, or a rate plan whose restrictions were never set at all. Fix the structure rather than the symptom and the check gets shorter.

Two habits make the log worth keeping. Write down what you deferred as well as what you fixed, because deferred items are the ones that become next quarter's incident. And keep it where the person who runs the check next month will find it — if that's a co-host, it needs to live somewhere they can open without asking you.

Twenty minutes is short enough that the usual reason for skipping it doesn't apply. Run it on the same day each month, in the same order, and the fourth or fifth run starts taking twelve.

FAQ

What if I find something I can't fix in the twenty minutes?

Log it and set a time to fix it, then finish the check anyway. A partial repair done in a hurry tends to create a second fault, and an unfixed item with a note beats a half-fixed item you can't reconstruct next month.

Should I run this on every channel or just the busy one?

Every one. The quiet channel is exactly where drift survives longest, because nothing about low volume surfaces a wrong rate — you just quietly don't sell the nights.

What's the single stage I shouldn't skip?

The mapping screen. Everything else produces a number that's wrong; a broken mapping produces a unit that's open in one place and closed in another, and that's the one that turns into two guests at the same door.

Drift is only visible if you go looking on a schedule, and twenty minutes a month is a cheap schedule. Connection, parity, mapping, log — in that order, on the same day, every month. Four channels on one calendar at localsbnb.com, each showing the rate and status it's holding, turns the parity stage from twenty clicks into one look.

---

Channel dashboards, the fields they expose and the way mappings are stored differ by platform and change between releases; this is general guidance rather than platform policy advice. Confirm against your own screens and each platform's current terms.