Four nominations, seven investigations, and a customer who audited us. Let’s get into it.
Something interactive to open with. Everyone plays from their own screen.
Living the values — four nominations this month
GTM, Product, Engineering, and Customer Success
Open roles and referrals
Seven teams, five minutes each
Learning out loud as a team
Sweepstake results, tool access, and the Q3 survey
The principles we hold each other to — a quick reminder before we recognise the people who lived them.
Living the Values is our program to recognise colleagues who’ve shown a specific example of living the Prerender values. Each all-hands we highlight nominations to help us remember what these values look like in practice.
Anyone can nominate a teammate — send a short summary to Lizzie. Four nominations this month.
Ownership. Belmin took responsibility for web application security testing — not as a task handed to him, but as an outcome he owned end to end.
Autonomy. When testing surfaced issues, he leveraged Claude to fix them himself rather than just bouncing them back to engineering.
Shared Outcomes. He managed an overloaded deployment pipeline, prioritising the critical work when it mattered so the whole team kept moving.
Ownership isn’t just about getting your own work done — it’s about staying with a problem when it gets messy, and telling people the truth about it before they have to ask. Aliya has done that every single month, on every project she leads.
March — pricing and free-trial migration. When she hit a billing mismatch for some Enterprise Plus customers, she didn’t just flag “something’s broken.” She traced it back to missing pricing flags and inconsistent manual migration steps from before her time, and came to us with a fix, not just a problem. She also quantified a revenue timing gap from mid-cycle upgrades and brought it to leadership before anyone asked her to. She went looking for the bad news so we could act on it early.
July — Moonshot POC data quality. Aliya found two issues that were quietly making the reports wrong: URL normalisation collapsing distinct pages, and crawl data including non-Googlebot traffic. Instead of letting the reports go out, she held them, had a constructive discussion with the team, and made sure they were fixed before release to customers.
I’d like to nominate the whole CS team — you are all brilliant — but today I want to particularly thank Kristina for living Autonomy and Shared Outcomes.
She returned from maternity leave in May and hit the ground running: no ramp-up, no hand-holding. Since May our median first-reply time dropped from 2.5 hours to under an hour, and P90 came down from 1.8 days to 6.6 hours and has held there. These are team results — sustaining 24-hour coverage takes all hands. Kristina holds the night shift with her little one beside her, 18:00–02:00 CEST (01:00–09:00 PHT).
She knows exactly when to escalate, consistently filing well-structured Linear tickets — correctly identified, documented and routed to Engineering: a caching rules bug, a Google Shopping query param causing render spikes, a missing CSV export column. Across complex cases — missing cache inventory, rendering issues on high-traffic sites, overage alerts, billing edge cases — she handles technically demanding questions with patience and precision, and flags risk before it escalates.
She’s recognised beyond CS, too. When Sales needed a deep render optimisation analysis on a complex enterprise account, Kristina delivered autonomously: Googlebot patterns, URL waste, bot behaviour, concrete savings estimates. James’s response: “amazing, thank you so much for all this.”
Thank you, Kristina.
Two things this quarter.
The Prism audit tool. Carli took it on and is getting it customer-ready essentially single-handedly. She’s project managing it herself — pulling the right people into the right conversations for clarification — and she designed the customer-facing report elements from scratch rather than waiting for someone to spec them for her. She’s also been deliberate about how she runs it: getting early feedback on a draft rather than building it by committee, which is why it’s actually moving.
The AI Insights launch. When we lost Product Marketing cover mid-launch, she stepped straight in. She found the launch wasn’t ready, and got every piece of comms written and shipped in under a week. She didn’t wait to be asked, and she didn’t let it slip.
It’s the clearest example of treating a deliverable as yours forever that I’ve seen this quarter.
Three years as one of our biggest customers — operating the whole time without a contract.
Matchr built their entire site with Lovable. It launched invisible in search. They had never heard of us. Claude recommended us, Claude did the integration, and they were live in under two hours — and we have the case study to prove it.
A new tool in the Prerender dashboard that catches AI crawler access issues at the source, before they affect your bottom line.
Where users went after the in-app announcement — and how deep they got.
Steps are shown in journey order, but the percentages have different bases — note that tab visits (80) exceed banner clickthroughs (31), because users also reached the tab without going through the banner. So these steps are not a strictly nested funnel.
Why it matters. The old Nexus was rigid, and lacked the autonomy to guide users in the way it judged best. The new one is faster, cheaper, more accurate, and helpful for both technical and non-technical users — moving us toward our 40% integration-rate goal.
A new report for 60 self-serve customers, generated once per customer, showing how pages served through Prerender appear in Google Search — visibility gaps, impressions, clicks, and indexing-related signals.
The POC is already doing what we needed it to do: validating customer interest, improving the report based on real feedback, and uncovering technical gaps we would not have found from internal testing alone.
The velocity improvements we reported last month continued unabated through July.
PRs merged per week, Feb 9 – Jul 20 2026. Q1 ran in the twenties and low thirties; since May we’ve held in the fifties to seventies — more than double the Q1 rate.
Total merges to master per week · git log origin/master --first-parent bucketed by ISO week (Mon-start) · Omega and human merges combined · Excludes the partial current week (W31, Jul 27+).
Support has always been in execution mode — Customer Success is now too. Here’s what we shipped in July.
Seven teams, seven investigations — findings from the work each team did this month.
Who’s outgrown their plan and we serve well — so we don’t upsell accounts we’re failing?
The slide this team published at the offsite showcase — “The Overage Achievers.”
Same data. Same MCP servers. Same question.
The health gate flips between 10/10 and 2/10 accounts passing depending on which metric is queried — the most likely root cause of the three-way divergence at the offsite.
Two criteria in the tightened definition were unworkable — and both failures were invisible until the numbers were re-run.
The accounts weren’t the problem. The definition was.
Wonderschool was one of the three “high-confidence” targets on the Bilbao list.
Wonderschool has a 36% cache hit rate.
Had we acted on the offsite list, we would have opened an upsell conversation with a customer we are failing.
Qualifying definition v3, revised 27 July — run across the full paid base rather than a sample.
Previous-cycle overage verified in ClickHouse. All 10 cross-checked against HubSpot for open deals and live conversations. Only 3 of the original Bilbao top 10 survived — HiDubai, blacksheep and MQ Sweden, the last of which the offsite list had missed entirely.
| # | Account | Plan | MRR | Usage | Cache hit | Cache-miss render | Prev cycle over? |
|---|---|---|---|---|---|---|---|
| 1 | HiDubai1 | Pro | $349 | 275% | 95.1% | 1.75s | Yes |
| 2 | pickafund.com | Pro | $349 | 182% | 97.4% | 2.50s | Yes |
| 3 | MQ Sweden AB (mq.se)2 | Pro | $349 | 170% | 98.0% | 0.53s | Yes |
| 4 | Alternative Airlines3 | Pro | $349 | 170% | 97.7% | 2.64s | Likely∗ |
| 5 | Wempe (wempe.com)4 | Pro | $349 | 146% | 86.6% | 2.43s | Yes |
| 6 | polette / blacksheep.io5 | Pro | $349 | 140% | 87.1% | 2.62s | Yes |
| 7 | overgear.com | Pro | $349 | 127% | 94.9% | 2.72s | Likely∗ |
| 8 | prezman.fr | Pro | $349 | 117% | 94.6% | 2.76s | Likely∗ |
| 9 | silpo.ua (Fozzy)6 | Pro | $349 | 104% | 70.3% | 1.41s | Yes |
| 10 | alternativeflooring.com | Growth | $149 | 182% | 88.6% | 1.25s | Likely∗ |
Given NRR is the H2 priority, that list may matter more than this one. It belongs with support, not sales.
Cross-checking the ten exposed the CRM as much as the accounts:
Render performance, cache hit ratio and latency don’t live in HubSpot in any form. This is the honest answer to “couldn’t we just pull a report?” — and a concrete specification for the cleanup already underway.
The method holds, with one condition — left vague, it produces confident answers that are wrong.
It only works when the definition is precise about which metric it means.
What do tickets say to fix — highest volume / frustration / MRR pain — does our roadmap match?
The slide this team published at the offsite showcase — “Billing/Usage Is Our #1 Customer Pain by Every Measure — but the Roadmap Is Aimed Elsewhere”
Three analyses in one view — feedback to MRR to churn.
What 14 months of support feedback says the roadmap should address.
Source: 1,196 HubSpot tickets (June 2025 – July 2026) classified on the 3-level taxonomy and attributed to the roadmap. Roadmap-relevant = feature/friction/performance signal only. Only non-Done backlog is counted, so “unaddressed” means no roadmap item and no currently-open backlog item — some were shipped earlier (Done), and areas like data-viz, recache and cache saw substantial recent delivery.
The MRR sitting behind open tickets right now.
Source: Prerender IRIS hubspot.tickets joined to the account CSV, 365-day window. Resolved = “Closed”.
The behavioral signal that predicts churn before a ticket is ever filed.
Source: ClickHouse audit_log plus analytics.customer_identity_map and Chargebee MRR, Jan 1 – Jul 22 2026 (Oct–Dec 2025 excluded for pricing/trial-migration noise). Statistics reported as observed associations, not causal claims. Mixpanel page/funnel and render-volume analyses specified but pending.
Every ticket classified on a 3-level taxonomy, then attributed to the product roadmap — 1,196 classified tickets, roadmap-relevant only.
| Stage | Tickets |
|---|---|
| Roadmap-relevant | 261 |
| → On the roadmap | 155 |
| → Unmet → in open backlog | 16 |
| → Unaddressed1 | 90 |
The roadmap is a small, deliberate slice. Only 22% of inbound (261) is roadmap-relevant; the other 78% (935) is operational/support, not roadmap material.
The real gap is ~90 asks. Of the 106 roadmap-relevant asks with no roadmap item, only 16 map to a currently-open backlog item — leaving ~90 with no roadmap item and no open backlog item.
The same 1,196 tickets, split twice.
Roadmap-relevant 261 (22%) · Operational / support 935 (78%)
On the roadmap 155 · Unmet 106
The 155 attributed tickets by roadmap item, against the 90 with no roadmap item and no open backlog item.
| Roadmap item | Tickets |
|---|---|
| Improving Integration | 131 |
| Onboarding revamp | 8 |
| Granular Bot Classification | 6 |
| Multi-WS / Access rights | 3 |
| GSC + Prerender integration | 2 |
| Activation experiment | 2 |
| AI Crawler Telemetry | 1 |
| Referrals | 1 |
| Change Propagation | 1 |
| Area | Tickets |
|---|---|
| rendering | 32 |
| billing_and_usage | 15 |
| url_filtering | 13 |
| recache_rules | 9 |
| api | 7 |
| cache_management | 4 |
| sitemap_integration | 3 |
| account_management | 2 |
| data_visualization | 2 |
| mobile_rendering | 1 |
| ui_ux | 1 |
Captured roadmap demand is almost all one item — Improving Integration (131 of 155). The machine-visibility bets draw ~0 current inbound: forward bets, not responses to today’s demand.
Five conclusions from attributing 14 months of support feedback to the roadmap.
Level 1 to Level 2, the nine largest areas — volume, the feedback-kind mix, and the specific thing customers wrote in about.
| Product area | Tkts | Feedback kind | Level 2 topics |
|---|---|---|---|
| billing_and_usage | 353 | billing_dispute 260, account_request 37, bug_report 36, feature_request 13, onboarding_question 5, integration_help 1, noise 1 | plan_upgrade_confusion 110 · overage_alert 73 · incorrect_charge_dispute 43 · payment_failure 28 · cost_cap 25 · bot_traffic_cost_surprise 23 · refund_request 18 · invoice_management 8 · usage_breakdown_by_domain 8 · payment_method_change 6 · account_reactivation 5 · billing_days_remaining 3 · discount_request 2 · unattributed 1 |
| rendering | 243 | bug_report 206, performance_complaint 29, integration_help 5, billing_dispute 2, positive_signal 1 | render_reliability 152 · render_timeout 36 · blank_page 31 · soft_404_prevention 11 · html_stripping 8 · custom_request_headers 2 · render_request_behavior 2 · blocked_scripts_config 1 |
| account_management | 210 | account_request 187, bug_report 18, onboarding_question 2, feature_request 1, noise 2 | plan_change 98 · cancellation 66 · notifications 15 · user_settings 11 · account_reactivation 9 · domain_addition 6 · duplicate_account 2 · referral_program 1 · legal_compliance 1 · unattributed 1 |
| integration_setup | 150 | integration_help 120, bug_report 28, feature_request 1, positive_signal 1 | cloudflare_config 63 · cdn_config 32 · framework_specific 25 · nginx_apache_config 11 · integration_not_detected 10 · dns_proxy_mode 5 · token_auth_error 4 |
| cache_management | 40 | bug_report 30, integration_help 4, performance_complaint 4, feature_request 2 | recache_queue_management 15 · bulk_delete 13 · cache_manager_reliability 4 · bulk_recache 3 · exact_url_search 2 · export_cache_data 2 · cache_list_pagination 1 |
| recache_rules | 35 | bug_report 23, feature_request 5, performance_complaint 4, onboarding_question 1, integration_help 1, account_request 1 | per_url_ttl 10 · recache_ignore_rules 8 · content_change_detection 8 · per_directory_ttl 4 · sitemap_based_schedule 2 · recache_jitter 2 · render_speed_control 1 |
| url_filtering | 29 | integration_help 13, bug_report 13, feature_request 3 | query_param_exclusion 8 · partial_url_match 8 · regex_pattern_support 7 · allowlist_mode 3 · ignored_url_status_code 3 |
| access_and_permissions | 29 | account_request 15, bug_report 11, integration_help 2, onboarding_question 1 | team_user_management 16 · role_based_access 6 · login_access 3 · sso 2 · token_security 1 · two_factor_auth 1 |
| onboarding_and_education | 25 | onboarding_question 13, bug_report 8, feature_request 2, integration_help 2 | integration_setup_confusion 6 · integration_checker_issues 6 · product_concept_confusion 6 · docs_and_guides 3 · waiting_state_ux 2 · metric_meaning 1 · unattributed 1 |
The remaining nine areas, same breakdown. Together with the previous slide this is all 1,196 classified tickets.
| Product area | Tkts | Feedback kind | Level 2 topics |
|---|---|---|---|
| api | 16 | bug_report 7, performance_complaint 5, feature_request 3, integration_help 1 | recache_api_filters 8 · insights_export_api 2 · cache_status_api 2 · api_token_scoping 2 · search_api_total_count 1 · cache_clear_api 1 |
| seo_analytics | 15 | bug_report 13, integration_help 2 | indexing_impact_reporting 12 · seo_scoring 2 · google_search_console_integration 1 |
| data_visualization | 11 | bug_report 9, feature_request 2 | charts 5 · sort_and_filter 4 · insights_export 1 · domain_list_view 1 |
| sitemap_integration | 10 | bug_report 6, integration_help 2, onboarding_question 1, performance_complaint 1 | sitemap_management_ui 6 · automatic_sitemap_polling 4 |
| unattributed | 10 | noise 7, bug_report 1, integration_help 1, unattributed 1 | — |
| machine_visibility | 8 | integration_help 4, bug_report 3, feature_request 1 | bot_classification 6 · telemetry_crawler_activity 1 · eligibility_status 1 |
| crawler_visibility | 7 | bug_report 6, feature_request 1 | crawler_activity_report 4 · url_discovery_source 2 · per_bot_breakdown 1 |
| mobile_rendering | 3 | integration_help 2, onboarding_question 1 | enable_mobile_rendering 2 · mobile_desktop_usage_visibility 1 |
| ui_ux | 2 | performance_complaint 1, bug_report 1 | inconsistency 1 · unattributed 1 |
Of 2,578 tickets across active accounts, 2,520 are resolved — only 58 remain open, and 40 of those belong to 25 active accounts carrying $48,565 MRR.
| Status | Tickets | MRR at stake |
|---|---|---|
| Waiting on us | 23 | $40,616 |
| New | 8 | $6,242 |
| Open | 4 | $34,113 |
| Waiting on customer | 4 | $2,678 |
| Waiting for something | 1 | $349 |
The ball is in your court. 23 of 40 open tickets are “Waiting on us” — carrying ~$40.6k MRR. These are the fastest wins: a response closes them.
Tickets and the MRR of the active accounts behind them — which open tickets, in which areas, hold how much revenue.
| Area | Tickets | MRR of active accounts |
|---|---|---|
| billing_and_usage | 10 | $7.4k |
| unclassified | 7 | $7.2k |
| account_management | 6 | $33.7k |
| rendering | 5 | $1.0k |
| cache_management | 3 | $29.9k |
| integration_setup | 2 | $398 |
| access_and_permissions | 1 | $1.8k |
| seo_analytics | 1 | $412 |
| url_filtering | 1 | $1.8k |
| recache_rules | 1 | $149 |
| crawler_visibility | 1 | $149 |
Do customers behave a certain way before they ticket — and do silent customers who never ticket behave the same way before they churn? They do.
| Stage | Count |
|---|---|
| Negative tickets in window | 558 |
| With company_id | 438 |
| Resolved to product identity | 215 |
| — already churned | 78 |
| No-ticket comparison sample | 437 |
One behavior dominates. In-product login collapse — not billing-page thrashing — is the earliest, most consistent churn precursor, and it is statistically significant (RR 1.89, OR 3.15, χ²=33.3, p<0.001) even among customers who never contact support.
Silent risk is invisible risk. Customers who submit negative tickets churn at 36% — below the 43.8% base. The highest-risk group is the silent majority: 43% of paying customers logged in zero times, and 59% of them churned — with no support signal at all.
Generalized from audit_log event sequences: logins, account and billing-state changes, manual cache clears, cancellations and reactivations.
All taxonomies · engagement collapse
steady logins → login rate down → only system/billing updates → non-renew / cancel
Human logins decay toward zero while the account still shows automated billing-cycle updates. Churned accounts averaged a fraction of retained logins in every cohort (rendering 6.5 vs 242; billing 32 vs 90; account-mgmt 13 vs 85).
Prevalence universal · Lead time weeks–months · Discriminative very high
billing_and_usage
charge / overage event → billing-state updates → “stop billing” ticket → cancel
A Chargebee charge/renewal change precedes an urgent billing ticket then cancellation. Aligns with Prerender’s #1 billing-surprise driver: overage charges. 73% of churned billing-cohort accounts fired a cancel event.
Cohort churn 36% · Lead time days · Discriminative medium
rendering · cache_management
manual cache-clear burst → recache attempts → rendering ticket → usage down → cancel / resolved · retained
Repeated manual cache-clears signal a customer fighting a rendering problem. Caveat: cache-clearing alone does not predict churn (~50% of both churned and retained clear cache) — it becomes predictive only when followed by login decline (leads to P1).
Cohort churn 29% · Lead time days–weeks · Discriminative low alone
The onboarding failure mode, the save window, and the one journey the audit log cannot see.
integration_setup
signup → integration ticket → low sustained logins → never activates → cancel
Early-tenure accounts that ticket about setup and never reach steady rendering. Highest cohort churn (52%), lower MRR ($49–$149). A distinct onboarding motion, not renewal-stage churn.
Cohort churn 52% · Lead time weeks · Discriminative medium
account_management · billing
cancel event → grace / outreach → reactivate
18% of churn-flagged accounts later reactivated. Retained accounts also show cancel events (account-mgmt 45%), i.e. successful saves. The interval between SITE_USER_CANCELLED and period-end is a concrete, actionable save window.
Reactivation 18% · Window cancel → period-end · Action win-back
Requires Mixpanel / render volume
The billing-page → pricing-page → checkout-abandon journeys are page-view sequences that audit_log does not record. Confirming event ordering around tickets and quantifying render-volume decline needs Mixpanel funnels plus the ClickHouse analytics table. Login-frequency is used here as the validated engagement proxy.
Bucketing both cohorts by in-window login count shows the same behavioral signature predicts churn in both.
Silence is the tell.
Zero-login customers churn at 59% vs 22% for active ones — a 2.7× spread, with no ticket ever filed. The behavioral signature works with or without a ticket, which is precisely what makes it usable for proactive, silent-churn detection.
Cohort B is a random sample of 437 paying customers (live Jan 1 2026, plan > $0) who submitted no negative ticket.
| Engagement | n | Churn |
|---|---|---|
| Silent · 0 logins | 187 | 59% |
| Low · 1–9 logins | 119 | 41% |
| Active · 10+ logins | 131 | 22% |
| Engagement | n | Churn |
|---|---|---|
| Silent · 0 logins | 21 | 86% |
| Low · 1–9 logins | 34 | 68% |
| Active · 10+ logins | 160 | 23% |
Ticket + silence is close to terminal. A negative ticket from a customer who has stopped logging in churns at 86%. The same silence signal, amplified.
Cohort A vs B headline. Ticketed customers churn at 36%; the no-ticket paying base at 43.8%. Support contact is mildly protective. The behavioral signature (login collapse) is the common thread — it works with or without a ticket, which is precisely what makes it usable for proactive, silent-churn detection.
Appropriate statistics, not invented metrics.
Treating “zero logins in the window” as a churn classifier on the no-ticket cohort: precision 59%, recall 59%, F1 0.59. As a first-pass, single-feature CS trigger that requires no support ticket, that is strong. Combining it with tenure, plan tier, and render-volume decline should push precision higher.
| Behavioral signature | Population | Churn rate | vs base | Leading-indicator strength |
|---|---|---|---|---|
| Silent + negative ticket | 21 | 86% | +2.4× | strongest — near-deterministic |
| Silent · no ticket | 187 | 59% | +1.4× | strong, invisible to support |
| Low logins · ticketed | 34 | 68% | +1.9× | strong |
| Low logins · no ticket | 119 | 41% | ~base | weak alone |
| Active · ticketed | 160 | 23% | 0.6× | protective |
| Active · no ticket | 131 | 22% | 0.5× | protective |
MRR at stake in the blind spot. Within this 437-customer sample alone, $9,214/mo of still-active MRR sits in silent (zero-login) no-ticket accounts — exactly the accounts today’s ticket-driven CS motion never sees. Extrapolated across the ~3,600 paying base, the silent-but-active pool is materially larger.
Three analyses, one answer — and it is not the one the roadmap is currently built around.
Add a customer-facing billing-transparency feature — overage clarity, usage visibility — as a roadmap priority.
Assemble a full account 360 into one renewal brief in minutes — and templatize it to scale beyond enterprise.
In Bilbao we started generic — everyone hands-on across the whole brief. It didn’t work. We split it instead: Giovanni on usage, Janine on support interaction, Amanda on pricing and picking the right customer for the setup.
The slide this team published at the offsite showcase — “Faire’s Usage Ran 47% Over Allowance — the July 3 Invoice Hit ~$54,900, Nearly 3× Their $19,200 Contract”
Babylist’s renewal is due Sep 25 and the account is already in T3 overage.
58.9M of 60M renders used — ~98% — projecting ~72.6M by renewal.
At a daily burn of ~199,000 renders. Cache hit rate is 46.8%, well below the 70% healthy threshold, and 2,105,650 4xx errors in the last 30 days confirm removed campaign or product pages still being crawled — burning render quota with no SEO benefit.
Eight numbers, each with the read attached — the layer Giovanni owned.
| Metric | Value | Read |
|---|---|---|
| Quota | 60M renders/yr | — |
| Used (period-to-date) | 58.9M (98.2%) | Overage locked in |
| Projected at renewal | ~71.7M (119%) | T3 |
| Daily burn | ~196K renders/day | — |
| Cache hit rate | 47% | Below 70% healthy |
| Live 4xx rate | ~90% | 12 months running — ~2M wasted renders/mo |
| Render mix | ~82% recache / ~18% on-demand | Recache is the main consumer |
| 12-mo trend | Doubled YoY | Peaked ~9.7M/mo (Apr), recache cut sharply since June — growth plus config-driven |
Overage is driven by chronic 4xx errors and aggressive recache TTLs, not clean traffic growth. Fixing both likely brings usage back inside 60M.
Per 1,000 renders — the current rate sits above the minimum but below the commercial target.
The two layers you only get by assembling the whole 360 — and the two that change how we open the conversation.
Genuinely over quota, but inflated by a ~90% 4xx rate and weak 47% cache efficiency. Effective rate ($0.495/1k) sits below the $0.60 target.
Real optimization headroom before any plan change — the account is a rate-increase candidate, not a size-increase one.
Billing trust is fragile — an unannounced overage would land badly. Worth confirming performance has held.
Renew at 60M renders. Do not increase the plan size.
Move the rate, not the quota.
Three open questions before the proposal goes out — and how much of this we’d stand behind today.
Which accounts and error types burn renders on non-200 pages — what is the waste and who do we contact?
The slide this team published at the offsite showcase — “~101.6M Renders Went to Non-200 Pages, Burning ~$3,095 for Us in 1 Month”
Last 30 days. Internal render-node cost is better approximated by render duration, not raw render count.
7.86% of renders. 43.13% of render time.
Roughly $20k/month of internal render-node cost. A count-based model put non-200 cost at about $3.6k/month — the duration-based estimate is ~$19.8k/month, about 5.5× higher.
How the internal non-200 cost figure is built, and the inputs behind it.
Internal non-200 cost = non-200 render time ÷ total render time × projected monthly render-node cost — that is 43.13% × $46,000 ≈ $19,840/month.
| Metric | Value |
|---|---|
| Total renders | 2,340,244,062 |
| Non-200 renders | 184,037,533 |
| Total render time | 740,213 hrs |
| Non-200 render time | 319,278 hrs |
| Projected render-node cost | $46,000/mo |
Last 30 days. Share of count, share of render time, and the cost that follows the time.
| Status | Share of all renders | Share of total render time | Est. monthly render-node cost |
|---|---|---|---|
| 3xx | 3.76% | 7.87% | ~$3.6k |
| 4xx | 3.87% | 24.38% | ~$11.2k |
| 5xx | 0.23% | 10.88% | ~$5.0k |
| Non-200 total | 7.86% | 43.13% | ~$19.8k |
Every bar is a percentage of the same monthly total — count on top, render time below.
The biggest driver is 4xx: only 3.87% of render count, but 24.38% of total render time, or about $11.2k/month. 5xx is much smaller by count at 0.23%, but expensive by duration because average render time is about 53.7 seconds, representing about $5.0k/month.
We know this affects customers. We cannot yet say which ones, cleanly.
A clean account-level view showing:
So the next step is not to estimate customer-side dollars broadly. The next step is to connect this render data to accounts and customer context.
Accounts whose crawler traffic is generating error-page or timeout renders — every one of which is billable. Ranked by render volume weighted for billing exposure, reliability escalations and churn risk.
| # | Account | Plan / MRR | Non-200 renders (30d) | Avg render | Allowance / exposure | CS signal |
|---|---|---|---|---|---|---|
| 1 | Popken Fashion Group | Enterprise+ · $13,333 | 6,977,484 | 6.6s | Inside · 3.9% | Urgent |
| 2 | RELAYTO | Pro · $349 | 976,286 | 1.3s | Over limit · 198% | Escalation |
| 3 | BingoPlus | Pro · $349 | 74,352 | 2.9s | Inside · 17% | Churn threat |
| 4 | Bill McIntosh | Starter · $49 | 47,564 | 2.4s | Over limit · 277% | Overage T3 |
| 5 | Fanatical | Pro · $349 | 341,131 | 3.4s | Inside · 69% | Escalation |
| 6 | Exponent | Growth · $149 | 96,228 | 1.2s | At limit · 97% | Escalation |
| 7 | Fortnum & Mason | Pro · $349 | 264,118 | 1.7s | Inside · 53% | Escalation |
| 8 | Sling / Dish | Pro · $349 | 306,730 | 2.4s | Inside · 62% | Ticket |
| 9 | Greentube | Pro · $349 | 35,155 | 3.6s | Inside · 10% | Escalation |
| 10 | WAM / Sosh | Pro · $349 | 71,829 | 2.9s | Inside · 16% | Escalation |
| 11 | Sportbet / fullslot | Growth · $149 | 19,723 | 5.5s | Inside · 28% | Ticket |
| 12 | Riders Share | Pro · $349 | 36,263 | 3.1s | Inside · 16% | Auto-alert |
Four priority actions off the watchlist — the accounts where doing nothing has a cost.
Explicit churn language plus chronic ~20K/wk failures and latency complaints since March. Owner outreach and a reliability plan this week.
“…we will stop using” — 10 tickets, 8 in the last 180 days.
~7M error renders looks alarming but sits inside a 240M custom limit (3.9%). Confirm no overage, then fix the 404 / redirect source.
“Pause rendering to avoid overages”
Genuine Extra-Render charges driven by errors — 2× and 2.8× plan. URL-filter / soft-404 config plus a credit conversation.
“Excessive x10 billing” · “URGENT: spending out of control”
At 97% of the 100K Growth plan, with errors making up 99% of billable usage. One bad week tips into overage — tune filtering now.
“prerender / exponent costs”
An 80/20 internal cost estimate, not exact accounting.
Use this as the internal cost baseline, then add the account-level breakdown as the next step.
We already have the signals. We just don’t use them proactively yet.
Who gets AI-bot traffic and how well do we serve each bot? The Machine Visibility story.
The slide this team published at the offsite showcase — “AI bots already drive ~30% of renders and reach 1 in 3 customers — but we serve indexing bots far worse than readers (64% vs 97% cache hit)”
Finding 1, re-run in July — a sampled estimate, not a full census.
Two integration issues mean some AI-bot traffic never reaches Prerender at all.
Sources: revision history of the GitHub Gist linked from the Cloudflare integration v2 docs; the CloudFront integration docs, confirmed in the workshop continuation thread in July 2026.
Before serve quality, the split that makes the rest of the story readable.
Sample of 220 accounts confirmed to receive AI-bot traffic, over a trailing 30-day window in ClickHouse prerender.analytics. Sample totals were extrapolated ~14× elsewhere in the analysis to approximate fleet-wide volume. Directionally representative, not an exact count.
The extremes are stark. The middle is messier than the Bilbao slide claimed.
| Bot | Type | Cache hit | Render on miss | Errors / timeouts |
|---|---|---|---|---|
| ChatGPT-User | Reader | 97.1% | ~406ms | 0.4% errors |
| PerplexityBot1 | Indexing | 91.1% | — | — |
| Perplexity-User2 | Reader | 83.9% | not measured | not measured |
| Claude-User2 | Reader | 77.3% | not measured | not measured |
| GPTBot, ClaudeBot, Meta-ExternalAgent, Bytespider | Indexing | 70–75% | 2.8–3.6s | double-digit |
| Applebot3 | Indexing | 64.3% | ~3.6s | 11.3% timeouts |
| Anthropic-AI4 | Indexing | 36.4% | — | — |
The most counterintuitive finding — a within-AI-bot-traffic effect, isolated to AI-bot requests only.
Fresh content is the content most likely to fail.
Caveats: drawn from 7 of the top-10-MRR accounts (3 omitted for near-zero AI-bot traffic) — not fleet-wide, may not generalise to smaller accounts. A deeper look at one other account in this dataset found its render-fail-on-miss was mostly expected 3xx redirects (locale/canonical routing), not real breakage; Northern Tool and EndPrize haven’t been checked the same way, so 69% and 54% could be similarly overstated. Render-on-miss is slow regardless of outcome — 6–13 seconds across these accounts.
Finding 5 — network-wide, Jul 21–24 2026, sampled as four 12-hour slices.
Hypothesis: it’s a very small portion that might get unproportional huge attention in AI Insights. Source: IRIS ClickHouse prerender.analytics, Jul 21–24 2026, network-wide.
Finding 6, and the questions we’d resolve before this goes any further.
We cannot say that bots behave in a similar manner when distributing their crawl budget.
Which high-MRR accounts are silently degrading — the watermelon: green outside, red inside — and what is the save-list plus outreach?
The slide this team published at the offsite showcase — “7 High-MRR Accounts Are Silently Degrading Watermelons — 2 Renew This Week and Need Outreach Now”
Trigger immediate outreach on the two time-critical renewals: Betika (Jun 27) and Radio Rottu (Jun 30).
Both are paying overages with no upgrade conversation underway.
Hand the four chronic $349-Pro overage-payers to CS & Account Management as Stage-2 Enterprise-upgrade cases.
Queue the remaining accounts by technical urgency.
Followed up on 27 July, one month after the offsite watchlist was published.
All 7 renewed. Zero cancellations.
But two lost ~90% of their revenue without cancelling, and one $18,000 invoice is unpaid.
Every account on the Bilbao list, with its renewal outcome and how its overage moved.
| Account | Flagged as | Renewal | Outcome | Overage then | Overage now |
|---|---|---|---|---|---|
| Betika | Degrading, acute | Jun 27 | Renewed, paid | $2,875 | $4,489 (+56%) |
| Radio Rottu | Chronic, recache loop | Jun 30 | Renewed, paid | $1,950 | $5,731 (+194%) |
| elenastrinasparco | Degrading, perf | Jul 17 | Renewed, paid | $1,801 | $2,253 |
| Sanistål A/S | Chronic, 2+ yrs | Jul 13 | Renewed, paid | $2,440 | $2,498 (flat) |
| Swank Films FR | Disengaged | Jul 2 | Active — $349, zero overage | $4,064 | $0 |
| insight.co | Soft-watch only | Jul 18 | Active — $729 | $4,105 | $380 (−91%) |
| digitelematica / eurospin | Watch, unpaid invoice | Jul 9 | $18,000 still unpaid | n/a | n/a |
The urgency was right but the window closed — Radio Rottu’s bill has nearly tripled. And one month is too short to score the screen: these are month-to-month plans, and the one confirmed churn signal has ~88 days of lead. Worth re-checking in September.
Nine possible causes were tested against a standard set in advance. One passed; a second holds with live examples.
Live now: Betika was billed $4,489 in extras on a $349 plan (12.9×). Radio Rottu, $5,731 on a $349 plan (16.4×). Both past the worst-1% threshold, both still climbing, no intervention on record. Caveat: very few accounts sit in that band — suggestive, not proven.
The rating tells us nothing about who will leave. The comment box does.
They don’t leave over it — and it only costs them money if they’re near their limit.
Comparing accounts of similar size, extra charges only rise in the biggest quarter (over ~283,000 renders/month): 69% of the wasteful ones get billed extra vs 49% of the clean ones, and 39% pay more in extras than their plan costs vs 21%.
In the three smaller size groups, wasteful accounts paid the same or less. In the smallest, 3% vs 12%. Under the limit a wasted render is free; over it, every one is billed.
Both of these accounts are green on any subscription dashboard.
A customer can stop paying us almost everything without ever cancelling.
No churn tool catches this, because nobody cancelled.
Ideas coming out of the follow-up, plus what the analysis does and does not cover.
login_users.id, not users.id. Billing is keyed on users.id. Joining on the wrong one gives a silent partial join, not an errorThese are month-to-month plans and the one confirmed churn signal has ~88 days of lead — one month is too short to score the screen. Worth re-checking in September.
Who are the worst-timeout accounts, and is it our infra or their site?
The slide this team published at the offsite showcase — “~10 Accounts Drive ~53% of Platform Timeouts — and It’s Customer-Side”
12 accounts · ~1.9M failed renders in 7 days · one root cause.
We add ~0ms of delay. The wait happens inside their page.
Every account is the same shape — and it isn’t the shape a timeout ceiling can fix.
This is where July departs from Bilbao. The offsite recommendation was to raise the 20s ceiling to 30/60s; on fresh data, the accounts already sitting on a 60s ceiling — currently Mosh, Enlabs and iFAST (888 moved off) — hang anyway.
Two ways to read “worst,” side by side.
FleetPride + DSW ≈ 770k timeouts.
Both since fixed — DSW went from ~18% of fleet timeouts to ~zero, FleetPride collapsed to 0.37%. The roster genuinely changes as accounts get fixed; that change is real signal, not methodology noise.
Barely rendering at all.
The prioritization rule: MRR × severity, not raw volume.
Two customer-side causes, inferred from render-time shape. Direct per-render confirmation needs engine logs.
The fix lives on the customer’s side. Our job: detect it, hand them the playbook, and make render-readiness part of enterprise onboarding.
One canonical way to produce the list, so every analysis returns the same clients for the same window. No hand-rolled queries.
public.domain_metrics only — the hourly per-domain rollupSame window, same clients. That kills the “everyone’s analysis disagrees” problem.
It does not produce the same companies every month. The roster genuinely changes as accounts get fixed or newly break — that change is real signal, not methodology noise. Never quote a prior month’s list for current outreach.
Enforced by one materialized view (PRE-3213), one saved query, one owner.
Re-verified on fresh 7-day data on 27 July. Every output is labelled with its exact dates.
A monthly loop, and the deliverable of this workshop. Future state: this becomes a dashboard — manual now, automated later.
Diagnosis done and verified.
Next: ship the readiness playbook, then run the CS loop on the top 5.
Mistakes are how we build a stronger, more resilient team. Let’s celebrate the courage it takes to try, fail, and improve.
No entries this month — but that doesn’t mean we didn’t make mistakes. Let’s keep this going, so everyone feels comfortable sharing what went wrong and what they learned from it.
Congratulations to Giovanni (Spain), who wins a $100 gift card.
And a round of applause for Peter (Turkey), the first to bow out of the tournament. Peter — we’ll donate $100 to a charity of your choice for taking part.
Submit an issue in Linear via the ACCESS team board.
Include the tool name, why access is required, and the urgency of the request. Follow the same process for requesting an entirely new tool.
19 participants. Overall sentiment is strong and positive.
See you next month. Keep building.