Technical Maintenance Procedures

Overview

This document covers recurring maintenance tasks, scripts, and operational procedures for the Super Portal and its integrations. These procedures should be run on the documented schedule or as needed.

Monthly: Statistics Generation

What: Market statistics (city-level and zip-level) are generated automatically on the 6th of each month via cron job.

What to verify:

• Stats generation completed without errors.
• Monthly Stats Report/Digest is available in the portal.
• Automatic emails to clients with attached stats were sent.

If stats are missing or incorrect:

• Check cron job logs for errors.
• Verify property data sync completed before the 6th.
• Re-run the stats generation job if needed.

As Needed: Property Data Cleanup (MLS Deletion Audit)

What: A reusable script reads properties from the SP database and queries them against the MLS to identify records that have been deleted from the MLS but still exist in the SP.

When to run:

• When agents report missing photos on property tiles (common symptom of MLS-deleted properties).
• After any bulk MLS data event (feed migration, Flex listing changes).
• Quarterly as a general hygiene measure.

Process:

1. Run the audit script (queries SP properties against MLS API).
2. Review the output list of deleted properties.
3. Remove confirmed deletions from the SP database.
4. Document the run and results.

Reference: Property Data Clean-Up Script

As Needed: Default County Backfill

What: When a new feed is added or default counties change, existing saved searches may not have the correct default counties set.

When to run:

• After adding a new data feed.
• After changing the default county list for an existing feed.

Process:

1. Identify all saved searches for the affected feed that have no counties specified.
2. Run the county backfill script to attach the new default counties.
3. Verify a sample of updated searches.

Example: When Waco launched, a script added default counties (McLennan, Hill, Limestone, Bosque, Falls, Bell) to all existing Waco searches that had none specified.

As Needed: Neighborhood Polygon Cleanup

What: Saved polygons with very few listings may clutter the neighborhoods dropdown without providing value.

When to run:

• When the neighborhoods dropdown becomes unwieldy.
• After significant MLS data changes in a market.

Process:

1. Identify saved polygons with fewer than 3 listings in the past 36 months.
2. Review the list with an admin (some low-listing polygons may still be relevant).
3. Remove confirmed low-value polygons.
4. Verify the neighborhoods dropdown reflects the changes.

As Needed: Bulk Neighborhood Polygon Upload

What: New market launches or neighborhood boundary updates may require uploading polygon coordinates in bulk.

Process:

1. Prepare a CSV file with polygon coordinates.
2. Use the bulk upload tool to import coordinates.
3. Verify polygons render correctly on the map.
4. Label all new polygons in the admin UI.

Markets with pre-loaded polygons: Austin/ABOR, Waco/NTREIS, Sarasota/Florida.

As Needed: School District Data Corrections

What: School district naming can change (e.g., "Hays ISD" renamed to "Hays CISD"). When the MLS updates, the SP database may contain stale records.

Process:

1. Identify the naming discrepancy (compare SP dropdown vs. Matrix).
2. Run a database update to change all instances of the old name to the new name.
3. Verify the SP dropdown matches Matrix.

Example: Hays ISD was renamed to Hays CISD. A database update changed all existing records from "Hays ISD" to "Hays CISD."

As Needed: FUB Data Migration for Deals

What: When agents change email addresses or users are migrated, deals may be associated with old/deleted email records.

Process:

1. Identify deals associated with the old email (check for "deleted" email records in the system).
2. Run a script to reassign deals to the current active email.
3. Verify affected deals display correctly in the portal.

As Needed: Rate Limiter Configuration

What: Public form rate limits are configurable per form type. Default is 3 submissions per email/phone/IP/content within 72 hours.

When to adjust:

• If legitimate leads are being blocked (increase threshold).
• If spam volume increases (decrease threshold or tighten window).

Configuration parameters per form type:

• Number of attempts allowed
• Time window
• Applicable rate limiter types (email, phone, IP, content)

Monitoring: SendGrid Email Event Processing

What: SendGrid events (delivery, bounce, open, click, unsubscribe) are processed via webhook into a background queue.

What to watch for:

• Queue backlog growing (indicates processing bottleneck).
• Bounce rates spiking (may indicate sender reputation issue).
• Unsubscribe rates spiking (may indicate email content or frequency issue).

If the queue is backed up:

• Check the background job processor logs.
• Verify the SendGrid webhook is delivering events.
• Check for database connection issues.

Monitoring: FUB API Health

What: The FUB API occasionally returns HTTP 429 (rate limit). The SP has a retry queue for these requests.

What to watch for:

• Sustained 429 errors (may indicate sync volume exceeds FUB's rate limit).
• Missing data in SP that exists in FUB (retry may have failed).

If data is missing:

• Check the retry queue for stuck jobs.
• Manually trigger a sync for the affected records.
• Review FUB API rate limit documentation for current thresholds.

Reference: Key Cron Jobs