Probe that checks delivery, not availability
`GET /api/health/contact` returns 200 if a lead can reach a person now and 503 if not. It checks two things separately: that the notification channel token is still valid (a real request to the provider, with an 8-second timeout) and that the request log is writable. The response is made up only of boolean values — never the token, the channel identifier or the bot name. The result is kept in memory for 60 seconds, so an external probe pressed often does not become traffic itself. When the provider is unreachable, the field becomes `null`, not `false`: “I do not know” and “invalid” are different states.
Log written before delivery, not after
Each request receives an identifier and is written to an append-only log, one JSON line per event, *before* notification is attempted. The second line, with the same identifier, says what actually happened: `delivered` or `failed`, with the reason truncated to 300 characters. The directory is created with `0700` permissions, the files with `0600`, and the path is deliberately placed outside the versioned directory, so the history survives a publication.
Acceptance check run after publication
A verification script opens each product page, in groups of three, and fails if the 200 code, the questions anchor, the example anchor or the canonical address is missing. It then checks the site map — that it does not contain language variants that cannot be opened and that it contains every product — and `robots.txt`, so that it does not block the resources needed for rendering. It also fails if content from an old client reappears on the page. It is a list of things that have already broken once.
Updates with a gate, not with hope
The deployment script refuses to start if the server has less than 500 MB free memory, runs `npm audit --audit-level=high` and stops at high-level vulnerabilities if you do not confirm explicitly, then builds from clean — `.next` and `node_modules` deleted, installation from the lock file. If the process does not appear `online` after startup, the script displays the last 50 log lines and exits with an error, instead of reporting success.
Restart with thresholds, not at random
The process restarts automatically above 500 MB memory, with a 4-second delay between attempts, exponential backoff and a stop after 10 unstable restarts — so that a crash loop becomes visible instead of consuming the server in silence. Grace period on shutdown: 5 seconds, then forced termination. Logs have date and time zone, in a single stream.
Duplicates handled, not counted twice
The same person, the same message, twice — a double click, a page reload — used to produce two identical notifications for a single request. Now the `sha256` fingerprint of the address + message pair is kept in memory for 10 minutes; the second submission receives the same request identifier and the `duplicate` tag, and the notification is not repeated. Only duplicates of a successful delivery are suppressed; a failed one is allowed through again.
Error codes that say what broke
400 for invalid data, 405 for the wrong method, 500 for a broken request body, 502 when the delivery channel responded badly, 503 when credentials are missing. The difference matters at 3 a.m.: 502 means “the provider”, 503 means “our configuration”. The visitor is told distinctly “we received the request, but could not notify” — not a false success.
Retention enforced by code, not promised in policy
The published privacy note says that form requests are kept for 24 months. The code applies exactly the same number: `LEAD_RETENTION_DAYS` defaults to 730, and files older than the threshold are deleted on each write, without a scheduler that can be forgotten. The IP address is truncated to the network prefix — `/24` for IPv4, `/48` for IPv6 — and the last hop is read from the header, not the first, because the first is sent by the client.
We find what nobody complained about either
The same code pass uncovered two things that no user had reported: the limit of 10 requests per minute could be bypassed entirely, because the first element was read from the forwarded address header — the one controlled by the client — and a phone-call initiation route was open anonymously, at our expense and from our number, although the component that used it was no longer mounted anywhere. Both fixed and verified in production.