The seven-day run decides the term
A server that passes a one-hour benchmark can still fail after the parser drifts, the retry queue grows, or the browser process leaves traces on disk. One hour proves provisioning. Seven days of actual workload prove the term.
The benchmark note worth keeping is: server, ram, worker_cap, queue_depth, p50, p95, crash_count, disk_growth, accepted_rows, provider_bytes. If those fields are blank after the test period, the job is not ready to commit. It is still a trial.
What the term discount actually costs
Proxynade bare-metal servers are available on monthly, quarterly, and semi-annual terms. Monthly is the highest per-month rate and the lowest commitment. Quarterly and semi-annual cut the effective monthly cost, but only recoup that savings if the workload uses the full term.
The discount is real. It does not help if the job changes after week two — whether because the target blocks a route, the parser needs a different hardware class, or the scraper moves to a different site entirely. A prepaid six-month term is still expensive when the real work moves somewhere else in month three.
| Term | Commitment | When it pays off |
|---|---|---|
| Monthly | One month, renewable | Testing phase, unstable parsers, new proxy routes |
| Quarterly | Three months prepaid | Workload stable for seven days, p95 flat, crashes zero |
| Semi-annual | Six months prepaid | Same as quarterly, plus stock risk is a concern |
The benchmark must include failure modes
The seven-day acceptance window is only meaningful if the server ran the bad parts of the job: browser restarts, parser deploys mid-run, a target that slows at noon, queue recovery after a route returns empty bodies, disk growth from screenshots or trace files.
A benchmark that only ran the happy path did not answer the term question. It answered a different question: does this server boot and stay up? That is table stakes, not a term decision.
Stock risk is a capacity decision, not a coupon decision
Some CPU and RAM combinations are hard to get. If a specific configuration is unavailable most months and the workload already covers its cost, locking the term can be less risky than hoping the same hardware slot is still there on renewal day. That is a supply argument, not a pricing argument.
Buying a longer term because it "feels safer" without a supply constraint is how idle capacity gets renamed headroom. The term length should follow the workload's stability, not the price card.
Three things must be stable before extending
Multi-month terms make sense when three things are simultaneously boring: the scraper (see Scrapy HttpProxyMiddleware for how proxy routing is wired at the framework level), the proxy route (see Playwright proxy docs for browser-based scrapers), and the target parser. If any one of those is still changing, the lower effective monthly rate can turn into prepaid waste.
The renewal note worth leaving is short: monthly_until=stable_7d; extend_when=p95_ok+crashes_zero+disk_flat+parser_unchanged. It keeps the decision tied to the job rather than the invoice.
Dedicated server term FAQ
When should I commit to a multi-month server term? After the server has run the full workload — browser restarts, parser deploys, queue recovery — for seven stable days. p95 latency flat, zero crashes, disk growth predictable.
What is the actual per-month cost difference? On Proxynade bare-metal, monthly is more per month than quarterly or semi-annual. The gap is real but only pays off when the workload is stable enough to use the full term.
What is stock risk and when does it justify committing early? If a specific CPU and RAM configuration is hard to get and the workload already covers its cost, locking the term reduces the chance of losing the hardware slot on renewal day.
What counts as a stable workload? The scraper, the proxy route, and the target parser are all unchanged. p95 response time is flat across the week, crash count is zero, and disk growth is predictable.
Does the monthly acceptance window include failure cases? It should. A benchmark that only ran the happy path — no browser restarts, no parser deploys, no queue recovery — did not answer the term question.
Term decision checklist
- Seven days of real workload logged, not a one-hour smoke test.
- p95 latency flat for the last three days of the run.
- Zero process crashes across the benchmark window.
- Disk growth rate known and within budget.
- Parser unchanged since the benchmark started.
- Proxy route class confirmed for the expected run duration.