Important limitations

When rental software is unavailable

Last materially reviewed 2026-09-19

Quick answerKeep a privacy-conscious continuity plan that does not depend entirely on the unavailable application.
Likely to work well when

✓ US hosts with one to five rental units

✓ Readers comparing booking systems and direct-booking routes

✓ Operators who can verify requirements before connecting live accounts

Important limitations

— Guaranteed occupancy or revenue forecasts

— Property investment or rental-law advice

— Enterprise hotel procurement

What to know

Define the essential work

Identify what must continue during an interruption: approaching arrivals, urgent guest questions and time-sensitive property access. Keep only the necessary continuity information in an appropriately protected place. This is not a recommendation to export every guest record indiscriminately. The aim is to avoid discovering during an outage that nobody knows how to reach the responsible person.

What to know

Distinguish outage from account trouble

Check the official provider communication and the specific error you can observe. Do not assume a global incident from one failed login or stale screen. Equally, do not repeatedly change credentials or reconnect channels while the cause is unclear. Record the time and affected operation so support can investigate a concrete failure rather than a general impression.

What to know

Avoid duplicate actions

An unavailable confirmation does not prove a request failed. Before repeating a booking change, cancellation or payment-related action, establish whether it completed. Preserve the original reference and use the supported recovery route. During uncertainty, assign one person to coordinate actions so several well-intentioned teammates do not create conflicting updates in different systems.

What to know

Reconcile after recovery

Review pending tasks, messages and any manual actions taken during the interruption. Check the records that matter rather than assuming every dashboard is correct because the login screen works again. Document the gaps found and update the continuity plan. We do not claim an uptime level or support response guarantee for any product discussed here.

What to know

Avoid speculative fixes while verifying the limitation

Use an incident record containing the affected action, time, property reference, last confirmed result and current responsible person. Separate confirmed provider communication from your own observation. Do not change several integrations in response to a single ambiguous error. When service returns, reconcile the original action before starting a replacement so the interruption does not create a second operational problem.

Source boundary

Where the safety evidence stops

This guide draws on Lodgify channel manager: merchant description, not reliability testing. Merchant-controlled records describe the provider’s own capabilities, terms or standards; they do not independently validate those claims. These records do not establish independent confirmation of the product claims.

Verify any current price, plan limit, label direction, compatibility rule, or commercial term that would materially change the decision. The dated source ledger shows the underlying records so this conclusion can be checked and updated.

Sources used for this page

These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.

  1. Lodgify channel manager: merchant description, not reliability testing — Merchant documentation · lodgify.com · Merchant-controlled · checked 2026-09-19