You Should Know Before They Do

The gate went down at one of our Aiken facilities on a Tuesday. By 4pm I had six texts from tenants.

That's the good outcome.

The failures that cost real money don't come with a phone call. Autopay breaks and nobody notices, including the tenant whose card didn't get charged.

Your rental page goes down on a Friday and you lose a weekend of move-ins. A call routing rule misfires and every inbound rings to voicemail for a week.

You find out when the numbers stop making sense.

They'll tell you when the gate is jammed, but they won't tell you when their autopay failed three times.

They will tell you when they spot trash on the ground, but they won't tell you when your rental checkout errored out and they called your competitor instead.

They don't know that's information you need. By the time you figure it out, the money is gone.

Remote management works. But it only works if you close the monitoring gap tenants can't fill for you.

Gate and access control is the loud end of the spectrum. Physical failure is self-reporting. A tenant who can't get through the gate calls within minutes. Your exposure window is measured in hours. Remote operators have largely solved this category.

Autopay and payment processing is where the spectrum flips. Most FMS platforms will surface payment declines. The data is there but The problem is it's sitting in a dashboard you're not checking every day. A payment run fails, the decline report populates, and it waits. You find out when the delinquency count climbs enough to look wrong. Exposure windows run two to four weeks before the signal is strong enough to catch without a proactive check.

Online rentals live in the same quiet failure zone. A web domain issue, a payment processor that stopped accepting your credentials, a unit availability feed that stopped syncing. The tenant hits an error and leaves. No call, no complaint, just a lost lead. A checkout that fails silently for 72 hours during a high-traffic weekend costs real units.

Call routing breaks differently. Not always total — usually partial. A rule set up for a holiday weekend that never got rolled back. An overflow number ringing to a disconnected line. A voicemail box that filled up. The vendor dashboard shows normal inbound volume because the calls hit the system. The fact that none got answered doesn't surface until you correlate call volume with move-ins and wonder why conversion dropped.

Automated communications compound slowly. Late notices that stopped after a template update. Welcome emails that never triggered for a specific move-in channel. A lien sequence that broke partway through. You don't see one number go wrong. You see delinquency creep up a point and a half over two months and you can't explain it.

Salary is only part of the equation. Local taxes, benefits, and employment costs add up quickly.

Use Oyster’s calculator to estimate the real cost of hiring globally, in seconds.

Estimate hiring costs

The NOI case is straightforward.

Storable says 59% of operators are worried an economic downturn hits demand this year. In that environment, leakage that was easy to absorb in 2021 isn't anymore.

The math on one missed autopay run: 100 units at $100/month, 15% don't get re-billed for three weeks. That's $1,500 in one cycle. At a 7% cap rate, that's $21,428 in asset value sensitivity from a single recurring failure.

A broken checkout that costs four move-ins a month is $4,800 annually — or $68,571 in asset value.

None of it shows up as an outage. None of it triggers a call.

A canary is a synthetic check. It doesn't wait for a tenant to report something. It confirms the system is working by testing it on a schedule.
Gate and access: weekly automated ping to your access control API. No response, alert fires.

Payment processing: daily check that the number of payments processed matches active autopay accounts with billing dates that day. Any meaningful gap, you review it.

Online rentals: weekly synthetic checkout test confirming the availability feed is live, the flow reaches confirmation, no errors thrown. Five minutes manually with a test unit, or automated with any uptime monitoring tool pointed at your checkout URL.
Call routing: compare inbound volume to answered rate weekly. A routing failure shows up as inbound climbing while answered rate drops. That ratio is the signal, not raw volume.

The operators planning to differentiate on service in 2026 are right about the direction. But that differentiation means nothing if the infrastructure underneath it is failing and nobody told you.

Build the canaries first. Then trust the system.

Both run on Make.com's free tier. Neither requires a developer.

This one confirms your facility's inbound number is reachable and getting answered.

It fires a test call on a schedule and alerts you if nobody picks up.

Step 1 — Create a new scenario in Make.com. Set the trigger to a Schedule module. Configure it to fire once per weekday at a time your facility should be staffed — 11am works for most operators.

Step 2 — Add a Twilio Call module. Point it at your facility's main inbound number. Set the call duration to 30 seconds. Twilio will dial the number, wait for an answer, and hang up. You need a Twilio account for this — free trial covers enough calls to run this indefinitely at one call per day.

Step 3 — Add a Filter after the Twilio module. Set the condition: call status is not equal to "completed." This catches voicemail pickups, rings that time out, and disconnected numbers.

Step 4 — Add a notification module after the filter. Use Slack (I personally run everything through slack), SMS via Twilio, or email, use whatever you actually check. Message: "Facility [NAME] did not answer at [TIME]. Check call routing."

Step 5 — Turn the scenario on. Make runs it every weekday. You hear nothing when it works. You get a message when it doesn't.

Total build time: 20 minutes. Cost: pennies per call.

This one confirms your daily autopay run processed the volume you'd expect. It doesn't replace your FMS, it just makes sure you don't go three weeks without noticing a billing failure.

Step 1 — In your FMS, confirm you have a daily payment report set to deliver by email. ESS and most major platforms have this under reporting settings. If yours sends a CSV attachment, even better.

Step 2 — In Make, create a new scenario. Set the trigger to a Gmail or Email module watching for that daily report in your inbox. Filter the trigger by sender address or subject line so it only fires on the payment report email.

Step 3 — Add a Text Parser module. Parse the email body or attachment for total payments processed. You're looking for one number: how many transactions ran today.

Step 4 — Add a Google Sheets module. You maintain a simple sheet with two columns: date and active autopay count. Pull yesterday's autopay count from the sheet.

Step 5 — Add a Math module or a Filter. Calculate the difference between today's processed count and yesterday's expected count. If the drop is more than 10%, trigger a Slack or SMS alert: "Payment count looks low. [X] processed vs [Y] expected. Check [FMS NAME]."

Step 6 — Add a Google Sheets module at the end to log today's count. The sheet stays current automatically.

Total build time: 30 minutes. Requires your FMS to send a daily email report — confirm that's enabled before you start.

Both scenarios do the same thing: stay completely silent when everything works, make noise the moment something looks wrong. You are not watching dashboards.

The system watches for you.

Luck is what happens when preparation meets opportunity.

— Seneca