Home Remodel Pro status

Scheduled work

10 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.

  No runs recorded

  No 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.

  webhooks-drain · every minute · last run never

  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.

  No runs recorded

  No 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.

  events-relay · every 5 minutes · last run never

  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; before that, the hourly work that talks to people — the cold-lead follow-up ladder, the invoice chase, the daily logs, the review asks, the walkthrough and care-visit reminders — and the QuickBooks work: money QuickBooks Payments took, caught up, then what is waiting pushed.

  No runs recorded

  No 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.

  leads-sweep · every hour · last run never

  If it stops: A missed first response is never marked, and the automated follow-ups, invoice reminders, daily logs, review asks, walkthrough and care-visit reminders all stop going out. Nothing is sent late when it comes back — each rung is judged against the clock again — so the cost is silence: leads go unchased and invoices unreminded until somebody notices. QuickBooks falls behind too: invoices wait unsent, and a payment whose webhook never came is not picked up until the pass runs again.

• Recomputes the read models, closes last month’s royalty statements, debits issued royalties that have an active mandate, detects launch progress, and asks whether any money moved in a shape worth a question.

  No runs recorded

  No 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.

  network-nightly · every day · last run never

  If it stops: Every dashboard reports yesterday, a month can go uncomputed, an issued royalty is not debited until the next night, 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 — and, every hour after, checks that today has them.

  No runs recorded

  No 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.

  blog-generate · every hour · last run never

  If it stops: Nothing an operator or a homeowner can see breaks; the marketing grid stops filling. A day it missed is not made up — the next run writes the day it runs in — and a topic that keeps failing goes to the back of the queue rather than blocking it, and head office’s blog screen says which topics and why.

• Gives the guides that have no picture of their own one — a few an hour, newest first — and does nothing when none is missing.

  No runs recorded

  No 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.

  blog-images · every hour · last run never

  If it stops: Nothing an operator or a homeowner can see breaks; a new guide wears the stock picture for its service instead of its own until the pass runs again. The daily writer still pictures what it writes, so only the backlog waits. It is idempotent — a guide with a picture is left alone — so a missed hour heals on the next one.

• Reads each connected location’s Google Ads and Local Services Ads spend, per campaign per day, into the Ads Manager’s record, then tells Google which ad clicks became walkthroughs and signed jobs.

  No runs recorded

  No 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.

  ads-sync · every day · last run never

  If it stops: Nothing is spent or changed — the read never writes to a campaign — but cost per lead, cost per signed job and return on ad spend stop moving and describe the last day read, and Google stops learning which clicks became jobs, so its bidding drifts back toward form fills. It re-reads thirty days each time and the results wait in an outbox, so a missed night heals on the next one; a location whose Google access was removed says so on its own screen.

• Observes each market’s own searches once a week, reads the peers’ pages, recomputes where every location stands, asks the coach for the week’s brief and drafts, and puts the week’s homeowner questions to an answer engine.

  No runs recorded

  No 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.

  local-sweep · every day · last run never

  If it stops: The board goes stale rather than wrong — it is recomputed from the observations on every read, so what it shows stays true of the week it was observed. Review velocity, which needs two observations a week apart, stops being measurable; no draft is written and nothing is published, because nothing here publishes without a person anyway. Share of answer stops being asked, and the board reads it as not current once its answers are a fortnight old.

• The flagship’s own automations: the operator’s switches in /admin/settings, held entirely during quiet hours.

  No runs recorded

  No 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.

  rv-reminders · every hour · last run never

  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.

• Calls any daily job that did not run in its slot, at half past the hour, so a skipped invocation costs half an hour rather than a day.

  No runs recorded

  No 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.

  jobs-catchup · every hour · last run never

  If it stops: A daily job the platform skipped or fired late stays skipped until its next slot: a day without new guides, a night the read models and the royalty close did not run, a week the markets were not observed. Nothing is lost, because each of those jobs heals when it next runs. It cannot help when the schedule itself is paused, since it is on the same schedule — that is what an outside check on /api/hrp/status is for.

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 4 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 /status

The 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. /api/hrp/status is the URL a check polls: HTTP 200 and signal ok when every job is on schedule, HTTP 200 and signal degraded when a job has never been recorded (a fresh deployment is not an outage), and HTTP 503 and signal degraded when a job is late or failing or the heartbeat table cannot be read. Until a check is pointed at that URL, 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 outcomes of authenticated requests the handler finished, how many were 2xx, 4xx and 5xx

Measured by hrp.api_usage answered_2xx, answered_4xx and answered_5xx

Sum the three columns over the windows you care about. A 2xx succeeded. A 4xx is a refusal the handler chose: a bad request, a missing row, a scope the token does not hold, the rate limit. A 5xx is the handler failing. A window with no answered rows has no rate, and zero would be the wrong sentence for it. A 401 is not in the count: it is refused before there is an authorization to file the row under. requests and cost on the same row are the rate limit, charged before the status was known, and they count a different set. None of this is whether the site was up.

Public API availability 99.9% monthly

Nothing measures this.

Nothing outside this deployment watches the API over a month, and a deployment cannot measure its own availability: the minutes it was down are the minutes it recorded nothing. What the handler did answer is counted separately, as answered_2xx, answered_4xx and answered_5xx on hrp.api_usage. That share is of authenticated requests the handler finished. It says nothing about the minutes the handler was never reached, which is the part a 99.9% figure is made of. Until a check outside this deployment has a history, this target has no measurement behind it.

Pointing a watcher at it

/api/hrp/status is unauthenticated and uncached. A check that only understands HTTP status codes reads it like this:

• 200, signal ok — every scheduled job has run on time.
• 200, signal degraded — a job has never been recorded. A fresh deployment says this. It is not an outage; the body names which jobs.
• 503, signal degraded — a job is late or failing, or the heartbeat table could not be read. Page on this.

The response header X-HRP-Signal is ok or degraded, for a check that reads a header and not JSON. Nothing is polling this URL yet. An outside watcher is the only thing that can measure whether this site was reachable, and pointing one here is a decision somebody has to make.