Tuesday, September 16, 2025

When Software Breaks at 3am: Building Reliable Rightmove Updates

Photo of Paul
Paul (Founder)

Paul is a software architect and director at Phillip James Lettings, who have arranged thousands of tenancies over twenty years. LetAdmin is what happens when you know both sides.

Product Features
Developer debugging timing issues with coffee at workspace

It's 3:14am on a Saturday. You're not awake—but your software is. A landlord just reduced the rent on their property (they set up the change Friday evening to go live overnight). LetAdmin should automatically update Rightmove with the new price. It should be seamless, automatic, invisible.

Instead, the update fails. Not every time—just sometimes. One in every twenty updates doesn't reach Rightmove. The portal shows the old price. Tenants enquire expecting the lower rent. You discover the problem Monday morning when the landlord calls asking why the listing still shows £1,200 instead of £1,150.

This is what happened in our production system during Week 38. Intermittent failures that only appeared under real-world load. This article explains what went wrong, how we fixed it, and why reliability matters more than flashy features.

The Problem: Rightmove Updates That Sometimes Don't Happen

Automatic Rightmove sync is table stakes. When you update a property (change price, mark as let, upload new photos), the system should automatically notify Rightmove. No manual export, no CSV files, no logging into portal dashboards.

But "automatic" is only useful if it's reliable. An update that works 95% of the time is worse than no automation—because you can't trust it. You still have to double-check everything manually, which defeats the entire purpose.

During Week 38's production deployment, we discovered our Rightmove sync was failing intermittently:

What Was Happening

Property updates triggered Rightmove sync correctly most of the time. But under heavy load (Friday evenings when multiple landlords made changes, Monday mornings when agents onboarded new properties), some updates failed with "record not found" errors.

The pattern was frustrating:

  • ✅ Update property price → Rightmove updated successfully
  • ✅ Update property description → Rightmove updated successfully
  • ❌ Update availability date → Rightmove update failed
  • ✅ Update bedroom count → Rightmove updated successfully
  • ❌ Upload new photos → Rightmove update failed

No obvious pattern. The same type of update would work, then fail, then work again.

Why This Is Unacceptable

Reliability below 100% breaks trust. If agents can't trust that Rightmove will update automatically, they'll manually verify every change. That's hours wasted checking what should be automatic.

Landlords expect accuracy. When they reduce rent to attract tenants faster, they expect the portal to show the new price immediately. A 3-day delay because of a sync failure costs enquiries.

Letting opportunities are missed. If a property's status changes from "Let" back to "Available" (tenancy fell through), but Rightmove still shows "Let," agents miss potential tenants searching for available properties.

What Was Causing the Failures: A Timing Problem

The issue was subtle—a "race condition" where updates happened so fast that the system couldn't keep up with itself:

The Sequence That Failed

  1. Agent updates property (changes price from £1,200 to £1,150)
  2. LetAdmin saves the change to the database
  3. LetAdmin triggers Rightmove notification ("property price changed—update your listing")
  4. Rightmove notification system tries to fetch the updated property data
  5. Database hasn't finished saving yet (still processing the transaction)
  6. Notification fails because it can't find the updated data

This happened in milliseconds. The notification system was too fast—it tried to sync before the database had fully committed the changes.

Why It Only Happened Sometimes

In development (my laptop), saves took 50-100ms. Notifications triggered after saves completed. No failures.

In production (Heroku with fast workers), saves took 5-10ms and notifications triggered in parallel within 2ms. Sometimes the notification reached Rightmove before the save completed.

Classic production bug: Works perfectly in testing, fails intermittently under real-world conditions.

How We Fixed It: Slowing Things Down (On Purpose)

The solution was counterintuitive: deliberately delay notifications by 1 second.

Why 1 Second?

Database transactions need time to fully commit. Even after the "save" completes from LetAdmin's perspective, the database needs a few milliseconds to ensure the data is visible to all systems.

Distributed systems have timing variations. In cloud environments (Heroku, AWS), different servers have slightly different clocks. A 1-second buffer accounts for this.

Rightmove doesn't care about 1 second. Portal updates don't need to be instant—they need to be correct. Waiting 1 second ensures every update contains accurate data.

One second prevents 100% of race conditions. Since the fastest possible save is ~5ms, a 1-second delay guarantees the database has committed before notifications trigger.

What Changed (From an Agent's Perspective)

Before the fix:

  • Update property price
  • Rightmove receives notification immediately (within 10ms)
  • 5% chance the update fails because data isn't ready
  • Manual intervention required to fix failed updates

After the fix:

  • Update property price
  • Rightmove receives notification after 1 second
  • 100% reliability—every update succeeds
  • No manual intervention ever needed

Trade-off: 1-second delay vs 100% reliability. Easy choice.

Why Reliability Matters More Than Speed

Software that works 95% of the time is broken. You can't rely on it, so you still do everything manually "just to be safe."

Software that works 100% of the time is invisible. You trust it completely and never think about it.

This is the difference between:

  • "Better check Rightmove to make sure the update went through..." (broken trust)
  • "Done. Rightmove is updated." (complete trust)

The Cost of Unreliability

Manual verification time: If agents spend 2 minutes checking each update "just to be sure," that's 100+ hours per year for a busy agency.

Missed opportunities: Properties showing incorrect information on Rightmove get fewer enquiries.

Landlord frustration: "Why does it take 3 days for Rightmove to show the price change?" Because the first two automatic updates failed and you had to manually fix it.

Loss of trust in the system: Once agents stop trusting automation, they revert to manual processes entirely.

Other Reliability Fixes We Made

The race condition fix revealed other timing issues we addressed:

Multi-Tenancy Context Preservation

LetAdmin is multi-tenant—multiple agencies use the same system with complete data isolation. Rightmove notifications need to know which agency's property changed.

Previously, this context was sometimes lost during the notification process, causing "access denied" errors. We fixed this by explicitly preserving agency context through the entire notification chain.

Impact: Notifications now always know which agency's Rightmove account to update—no more permission errors.

Retry Logic for Transient Failures

Networks fail sometimes. Rightmove's API might be slow or temporarily unavailable. Hard drives occasionally hiccup.

We added intelligent retry logic:

  • First attempt fails? Wait 5 seconds, try again
  • Second attempt fails? Wait 30 seconds, try again
  • Third attempt fails? Wait 5 minutes, try again
  • After 3 attempts: Alert operations team (something is seriously wrong)

Impact: Temporary glitches don't cause permanent sync failures—the system automatically recovers.

What This Means for Letting Agents

You never think about Rightmove sync. It just works, every time, even under heavy load.

Property updates appear on portals within seconds (well, 1 second delay, but who's counting?).

No manual verification needed. When you change something in LetAdmin, you trust it reaches Rightmove correctly.

No failed updates to fix. The system handles transient failures automatically—you don't get alerts about "sync failed, please retry manually."

Scales with your agency. Whether you update 1 property or 50 properties at once, reliability stays at 100%.

The Boring Work of Building Reliable Software

This isn't a sexy feature. There's no demo screenshot. No impressive workflow diagram. No "wow factor."

It's just... making things work correctly. Every time. Under all conditions.

But this is what separates professional software from prototypes:

  • Prototypes work in ideal conditions
  • Professional software works in real-world chaos

Real-world chaos includes:

  • Heavy load from multiple users
  • Network hiccups
  • Database replication lag
  • Server clock variations
  • Intermittent API slowness

Good software handles all of this invisibly, so you never know it's happening.

We'd Love to Hear from You

Have you ever had "automatic" portal sync that didn't actually work reliably? It's more common than vendors admit—automation that works 90% of the time and requires constant manual verification.

How much time does your agency spend double-checking that portal updates actually happened? Be honest—if you don't fully trust your software, you're checking manually.

Would 100% reliable Rightmove sync change how you manage properties? We think complete trust in automation is the only way automation is actually useful.

Get in touch: paul@letadmin.com


LetAdmin is in active development, built by letting agents for letting agents. These reliability fixes were discovered in production at Phillip James (370+ properties) during real-world usage. If you're interested in seeing how it works or want to join the priority list, we'd love to hear from you.