Overview
ArrivHQ keeps a per-attempt audit log of every calendar sync. The right-side Sync Overview panel on Property → Setup → Connections shows you whether your calendars are healthy at a glance: success rate, what's been imported, and the most recent attempts.
This article explains what the panel shows, what "restored from feed" means, and what to do if syncs are failing.
How it works
Every 15 minutes (or whenever you click Sync Now), ArrivHQ:
- Connects to your iCal URL on Airbnb / VRBO / Booking.com / etc.
- Parses the events in the feed.
- Compares them to the reservations already in ArrivHQ for that connection.
- Creates new reservations (events in feed, not in ArrivHQ).
- Updates date or guest-name changes (event matched to existing reservation, dates differ).
- Cancels reservations that are no longer in the feed (guest cancelled the booking on the platform).
- Restores reservations that re-appeared in the feed after you previously deleted them in ArrivHQ.
Each attempt produces one entry in the sync history.
The Sync Overview panel
| Field | What it means |
|---|---|
| Success rate (24h) | Percentage of syncs in the last day that completed without error. 100% is the target; below 95% suggests a flaky feed worth investigating. |
| Reservations created (30d) | New bookings imported from the feed in the last 30 days. |
| Updated | Existing reservations whose dates or guest name changed in the feed. |
| Cancelled | Reservations no longer in the feed (guest cancelled the booking). |
| Restored from feed | Reservations you had previously deleted in ArrivHQ that the iCal feed brought back. See Restore behavior below. |
| Avg sync time | How long the typical successful sync takes end-to-end. Should be under 2 seconds. |
| Recent syncs | Last 10 sync attempts with status dot, counts, and timestamp. Hover for the error message on failed syncs. |
The panel respects whichever connections are tied to the property — if you have one Airbnb and one VRBO connection on a property, the stats aggregate across both.
Restore behavior
If you delete a reservation in ArrivHQ that came from a calendar sync, ArrivHQ marks the row as deleted but does not tell the upstream platform. The booking still exists on Airbnb / VRBO / etc.
When the next sync runs and finds the same booking in the feed (matched by its unique iCal UID), ArrivHQ restores the reservation. Specifically:
- The
deleted_attimestamp is cleared so the reservation is visible again. - iCal-sourced fields (check-in date, check-out date, status) are updated from the feed.
- Your custom edits are preserved — guest name overrides, internal notes, channel attribution, nightly rate, anything you typed yourself stays put.
This is intentional. Deleting a reservation that the feed still owns would otherwise mean either (a) it re-appears as an empty new row losing your customization, or (b) it stays gone forever and you're confused why the booking shows on Airbnb but not in ArrivHQ. The restore behavior gives you the best of both: deletion is reversible by the source of truth (the feed), and your manual work isn't lost.
The Sync Overview panel surfaces a Restored from feed count when this happens, so you can spot when a reservation came back unexpectedly.
If you want a reservation to stay deleted regardless of what the feed does, the right action today is to either disconnect that listing connection (Setup → Connections → Remove) or pause it. Per-reservation "block from re-sync" is a planned follow-up; ping support if you need it sooner.
Troubleshooting failed syncs
Hover over a status dot in the Recent syncs list to see the error message. The most common causes:
| Error pattern | What it usually means |
|---|---|
403 Forbidden / 404 Not Found | The iCal URL was rotated or revoked on the platform side. Re-export it from your listing platform and update the connection. |
Connection timeout / ETIMEDOUT | Transient network issue — ArrivHQ retries with exponential backoff. Five+ consecutive failures and the connection auto-pauses; you'll get a Telegram alert. |
Failed to parse iCal feed | The feed format changed or the URL is returning HTML (e.g. a login page). Verify the URL still works in a browser. |
Auto-paused after 10 consecutive failures | ArrivHQ stops retrying to avoid hammering a broken endpoint. Click Resume after fixing the URL to retry. |
After 5 consecutive failed syncs on a connection, the team Telegram alert fires automatically (cooldown: 24 hours per connection so we don't spam you during an extended outage).
Privacy
Sync error messages are scrubbed before storage — auth tokens in iCal URLs (Airbnb's ?s=, VRBO's ?p=, etc.) are replaced with *** so credentials don't leak into the audit log.
Limits and retention
- Sync history is retained for 90 days. Older rows are automatically pruned.
- Each connection syncs every 15 minutes by default. Failing connections back off exponentially up to 90 minutes between retries.
- The Sync Now button is rate-limited to once per minute per connection.
FAQ
Why is my success rate not 100%? Most failures are transient — the upstream platform returns a 503 or your network blips for one sync. As long as the connection recovers and the latest attempt succeeds, the only impact is a 15-minute delay on importing that batch.
Why did a reservation come back after I deleted it? Because the booking still exists on Airbnb / VRBO / wherever. The feed is the source of truth for synced reservations. See Restore behavior.
Can I see who deleted a reservation that got restored?
Yes — the audit log records both the original deletion (reservation.deleted with the user_id) and the restore (reservation.restored_by_sync with the connection_id). Visit /ops/logs → Audit tab if you have superadmin access.
Will deleting a reservation cancel it on Airbnb? No. Cancellation has to happen on the platform side — Airbnb / VRBO / etc. don't expose write APIs to ArrivHQ. ArrivHQ syncs read-only.