Where This Started
MetricPoints did not start as a grand product category.
It started with a much smaller irritation: websites were breaking in ways that normal monitoring did not explain. A Content Security Policy report would hint at a blocked script. A browser error would show up in production. A security header would disappear after a hosting or plugin change. A client would say a form was broken, but the site was technically "up."
At first, I was thinking mostly like a developer. I wanted clearer CSP reporting, better browser error capture, and fewer mystery failures. Those are still useful pieces. But the more I looked at real agency work, the more obvious it became that the pieces were not the whole problem.
The Real Problem Is Trust
For an agency, a broken website is not just a technical incident. It is a trust incident.
The client does not care whether the failure came from a plugin update, a missing header, an expired certificate, a bad deploy, a spam-control change, a third-party script, or a checkout provider. They care that their site stopped doing something important and the agency did not know first.
That changes how I think about the product. MetricPoints cannot just collect raw technical events. It needs to help answer the operational question: which client sites need attention right now, why, how serious is it, and what evidence do we have?
The Early Signals Still Matter
- CSP reports can show unexpected scripts, blocked resources, and policy drift.
- Browser errors can show real visitor failures that synthetic uptime checks miss.
- Security headers can reveal host, CDN, cache, or deployment drift.
- DNS, TLS, domains, redirects, robots, and sitemaps can quietly change the way a site is discovered or reached.
- Form, checkout, analytics, and email checks can reveal failures that matter directly to the client's business.
- WordPress plugin context can explain what changed close to the time the site started failing.
What I Got Wrong At First
The early version of the idea was too feature-shaped.
CSP monitoring over here. Error tracking over there. Header checks somewhere else. Each feature made sense, but agencies do not wake up wanting another place to check raw logs.
They need a portfolio view. They need prioritization. They need to know whether an issue affects a business-critical path. They need the history and evidence when a client asks, "What happened?"
That is the product lesson I keep coming back to: data is only useful if it helps someone make a better decision under pressure.
The Direction Now
MetricPoints is moving toward agency website assurance.
That means the site is the primary thing being monitored, and the agency portfolio is the primary view. Raw observations should remain available, but they should not automatically become customer-facing warnings or noisy alerts.
A single stale CSP report should not make a site look broken forever. A delayed worker should not be mislabeled as a client-site outage. An old JavaScript error should remain evidence, but it should not keep a site in warning forever after recovery.
The product has to be honest about current health, monitoring coverage, and uncertainty.
Principles I Am Designing Around
- A site can be up and still unhealthy.
- Business-function failures outrank advisory security findings.
- Monitoring gaps should be visible instead of hidden behind false green checks.
- Related observations should become one understandable incident when the evidence supports it.
- External monitoring must work for any website, with WordPress as an optional deeper evidence source.
- Technical evidence should stay available beneath simple summaries.
- Automation should start with observation and recommendation before any active change.
Why WordPress Is Important, But Not The Whole Product
A lot of the agencies I know manage WordPress sites, so WordPress context matters.
The plugin can tell MetricPoints things an outside check cannot reliably know: plugin changes, WordPress health, cron status, mail attempts, WooCommerce context, and application-side errors. That is valuable evidence.
But I do not want the product to depend on WordPress. Many useful checks can and should happen externally: uptime, DNS, TLS, redirects, public pages, forms, security headers, CSP, browser errors, analytics, visual drift, and synthetic journeys.
The WordPress connection should raise confidence and explain likely causes. It should not turn MetricPoints into a generic WordPress-management product.
What Helpful Looks Like
The kind of output I want MetricPoints to produce is practical.
Not: "47 CSP violations, 12 browser events, 1 header warning, and 3 plugin updates."
More like: "The contact form started failing after a form plugin update. The page is reachable, but submissions are blocked and no confirmation email was observed. Browser errors increased on the form page during the same window."
That is something an agency can investigate, assign, explain, and fix.
What I Have Learned
- Monitoring has to respect the difference between evidence and incidents.
- Agency owners need fewer better alerts, not more raw notifications.
- A green status without recent evidence can be worse than no status at all.
- The most valuable checks are often boring: forms, checkout, DNS, TLS, redirects, and key pages.
- Security posture is part of site health, but it has to be prioritized by likely impact.
- The product should help the agency look prepared, calm, and honest with clients.
Where This Is Going
The goal is still simple to say: know before the client knows.
The implementation is the hard part. It means better signal correlation, clearer site health, stronger monitoring coverage, practical evidence, quieter alerts, and a portfolio view that tells agencies where to spend their attention.
That is the version of MetricPoints I am building toward now. CSP and browser events are still part of it, but the real product is the assurance layer around the client sites an agency is trusted to protect.