Platform status
Home Remodel Pro status
A scheduled job has never been recorded running.
This page is served by the thing it describes. If you can read it, the site is answering requests — and it can never tell you the opposite, because the minutes worth measuring are exactly the minutes nothing here was running to measure them. What it does report is whether the scheduled work below has been running, which is a question a deployment can answer about itself honestly.
Scheduled work
Six jobs run on a schedule. Each writes a row when it starts and again when it finishes, so a gap in the record is written by the runs on either side of it rather than by the run that did not happen. A job reads late after 3 missed runs plus 3 minutes of slack, and failing after 2 failures in a row — one bad pass is weather.
Sends the webhook deliveries the relay queued, to the servers integrators registered.
RunningRunning on schedule.
If it stops: Nothing is lost — a delivery waits in hrp.webhook_deliveries until somebody drains it — but every integration goes quiet, and the first retry is a minute out, so a drain that runs less often than the shortest backoff turns a one-minute retry into however long the gap is.
Delivers domain events to their consumers: the activity feed, the read models, the build plan, the contact behind a lead.
RunningRunning on schedule.
If it stops: A signed estimate gets no build plan, a captured lead grows no contact, the homeowner’s feed stops filling and every dashboard figure goes stale. Nothing is lost and nothing is right either — this is the job whose silence is felt first.
Notices a lead nobody answered inside the first-response promise, and parks one that has gone quiet in a stage nobody is mid-work in.
RunningRunning on schedule.
If it stops: A missed first response is never marked, so the list stops wearing the thing it exists to show. It never messages a homeowner, so nothing goes out late — the cost is that silence stops being detected.
Recomputes the read models, closes last month’s royalty statements, detects launch progress, and asks whether any money moved in a shape worth a question.
No runs recordedNo run has ever been recorded. On a fresh deployment that is what it should say; anywhere else it means the schedule is not reaching this route.
If it stops: Every dashboard reports yesterday, a month can go uncomputed, a location that finished its launch track stays onboarding — and the anomaly sweep raises nothing, which looks exactly like a clean night. It is idempotent and refuses work that is not ready, so a missed night heals on the next one; a missed week does not heal by itself.
Writes the day’s guides against the coverage grid — every service in every city an open territory serves.
RunningRunning on schedule.
If it stops: Nothing an operator or a homeowner can see breaks; the marketing grid stops filling. A topic whose run failed is left uncovered on purpose, so the next run picks it up.
The flagship’s own automations: the operator’s switches in /admin/settings, held entirely during quiet hours.
RunningRunning on schedule.
If it stops: The cold nudges and the station digest stop. Everything it sends is something the operator switched on, so the failure is silent by design — which is the argument for this page.
Runs are kept for 35 days. Recording a run is allowed to fail without stopping the job itself — a status table must never be the reason the relay stops relaying — so a gap is a missed run or a run whose bookkeeping failed. That is rarer than the thing this exists to find, and it is said here rather than left to be assumed.
What is measured, and what is not
The platform’s targets are in its specification; this is which of them anything actually measures. 2 of 3 have nothing behind them, and they say what would.
- Scheduled work every job runs on its schedule and finishes
Measured by
hrp.job_runs, read by /statusThe one availability question a deployment can answer about itself honestly, because a gap in the record is written by the runs on either side of it rather than by the run that did not happen.
- App availability 99.9% monthly
Nothing measures this.
Nothing outside this deployment watches it. This page is served by the thing it describes, so it can report that the site is up and never that it is down — the minutes worth measuring are exactly the minutes nothing here was running to measure them. /api/hrp/status exists to be polled by something that is not us; until an external check is pointed at it, 99.9% is a target with no measurement behind it and this page says so rather than printing a number it cannot substantiate.
- Public API availability 99.9% monthly
Nothing measures this.
There is a second reason this one is unmeasured, and it is closer to home: hrp.api_usage counts requests and weighted cost per authorization and does not record what was answered. So even the bounded version — "of the requests that reached us, how many succeeded" — has no data behind it. That is a smaller piece of work than an external check and it is not this issue’s; recording a status code per request changes what §11’s rate-limit accounting writes, and it is named here rather than done quietly.
Pointing a watcher at it
/api/hrp/status answers the same report as JSON, unauthenticated and uncached. It is 200 when every job is running and 503 when one is not, so an external check can treat it as a health endpoint without parsing anything.
Nothing is polling it yet. That is the gap this page does not close: an outside watcher is the only thing that can measure whether this site was reachable, and pointing one at this URL is a decision somebody has to make rather than a feature somebody can write.