DEV Community: Artem Meleshkin

Freshping alternative for agencies — where does your client portfolio go when it shuts down?

Artem Meleshkin — Mon, 10 Aug 2026 18:16:46 +0000

Freshworks is sunsetting Freshping on March 6, 2026. For a lot of freelancers and small agencies, Freshping was the quiet default: free uptime checks and a free status page, good enough that nobody thought about it again after setup. That's exactly why the shutdown is going to catch people off guard — the tools you never think about are the ones you forget to replace until they're gone. This isn't a takedown of Freshping. It's a straight answer to the question its former users now have: where does a client portfolio go next, and what should you actually check before you commit it somewhere new?

What's actually happening

Freshping was Freshworks' free uptime monitor: ping-based availability checks plus a public status page, aimed at people who wanted the basics without paying for enterprise observability. It did that job well enough to pick up a real following among developers, freelancers and small studios keeping half an eye on a handful of sites — their own, or a client's. Freshworks has announced it is retiring the product, with a shutdown date of March 6, 2026. After that date, the monitors stop running and the status pages stop resolving.

If that's the only monitoring a client site has, this is not a cosmetic problem. An outage that happens the week after Freshping goes dark is an outage nobody is watching for.

What to check before you commit a portfolio somewhere new

A shutdown is a forcing function, and forcing functions produce rushed decisions. Before you sign up for the first "Freshping alternative" article that shows up, run down this list — it's the difference between a monitor that works for a single site and one that works for an agency managing a portfolio of them.

Being honest about the free-tier shape

Here's where we won't oversell the comparison. Freshping's free plan was generous in a specific way: a fairly large number of separately pinged URLs, each getting its own uptime check. If what you need is "tell me when any of these fifty endpoints stops responding," that shape is genuinely useful, and we're not going to pretend our free plan replicates it — it doesn't.

Pingvera's free plan is organized differently: up to 5 sites, each checked from multiple regions every 1 minute, with a status page included. It's not a bigger or smaller number of the same thing — it's a different unit. One "site" on our free plan isn't one ping; it's the availability check, TLS certificate, domain expiry, and (for WordPress/WooCommerce sites) internal health of that one property, bundled together.

For an agency, that difference usually cuts in your favor. You don't manage fifty anonymous URLs — you manage a handful of client relationships, and each one needs to be watched properly, not thinly. Five client sites with full coverage is a more useful free tier for that job than fifty pings that only tell you the server answered. But if your actual use case is a long flat list of endpoints rather than a portfolio of client properties, say so to yourself honestly — that's a real difference in shape, not a detail.

Beyond the ping: what an uptime check was never built to see

This is the part that has nothing to do with Freshping specifically — it's true of ping-based monitoring as a category, Freshping included. A monitor that watches whether a URL responds is watching the server, not the business running on top of it. That gap is where client relationships actually get lost:

The contact form stopped delivering leads. The page loads, the form submits, the "thanks" message appears — and the email never makes it out of wp_mail(). A ping confirms the server is up. It says nothing about whether the lead arrived.
The store stopped taking orders. A payment gateway left in test mode, a checkout broken by a plugin update, bots grinding stolen cards through checkout — while uptime stays green the entire time, because the storefront is loading fine.
WordPress is quietly compromised. A website can return 200 OK and still be hacked — a backdoor, modified core files, a site dropped from search results. None of it fails a ping.

Pingvera checks the parts a ping can't: form and lead delivery confirmed in real time, WooCommerce orders watched against a baseline so a checkout that goes quiet gets flagged even while every technical check is green, a unified timeline that lines up business events, deploys and incidents on one clock, plus domain expiry, SSL, and signs of compromise or de-indexing. It goes past "is the site up" to "is the site working as a business" — which is usually the question the client is actually asking, even when they phrase it as "why is the site down."

Ordinary uptime pinging vs. business observability

White-label status pages and client reports

One thing Freshping got right for its audience: a status page cost nothing extra. That's worth preserving in whatever you migrate to. Pingvera's status pages are included on every plan — including free — and can sit on your own domain via a CNAME record with automatic TLS, so a client sees status.youragency.com, not a third-party subdomain. Reports work the same way: white-label, in plain business language, built for a client to actually read rather than a graph of response times they'll skim past.

Alerts that don't cry wolf

A single failed check from one location is not the same thing as an outage — it might be a network blip near the probe, not the site. Confirming from multiple regions before an alert fires is what separates "my monitor pages me for real problems" from "my monitor pages me and I've learned to ignore it." Alerts route to Telegram, email, Max, VK or a webhook, and the agent that runs on a client's server (optional, for deeper host-level checks) is strictly one-way: it sends data out and never accepts a command back in. Nothing runs on a client's machine because Pingvera decided to run it — the service observes and explains, it doesn't act.

Migrating before March 6, 2026

There's no automated import from Freshping — setting up a new site takes a few minutes, roughly the same amount of time it took to add a URL there in the first place. The only real deadline is the shutdown date itself. Practically, that means:

Sign up free and add your client sites — up to 5 with no card required.
Point a status-page subdomain at your own domain with a CNAME, before clients need to look for it.
Set up alert channels (Telegram is the fastest to wire up) so the first alert isn't the first test of whether alerts work.
Do this before March 6, 2026, so your new monitoring already has a running history — and a quorum of confirmed checks behind it — by the time Freshping goes dark, instead of starting from zero on the same day the old monitor disappears.

Frequently asked questions

When is Freshping shutting down?

Freshworks is sunsetting Freshping on March 6, 2026. After that date the free uptime monitoring and status pages many freelancers and agencies used for client sites will no longer run, so anyone still on it needs a new home before then.

Is there a free Freshping alternative?

Yes — Pingvera's free plan covers up to 5 sites at a 1-minute interval with a status page included, no card and no trial clock. It's organized around a client site rather than a count of pinged URLs, which is usually the more useful shape for an agency watching a portfolio.

What should agencies look for when migrating off Freshping?

The check interval on the free plan, whether status pages are included or sold separately, whether reports can be white-labeled, whether checks go past uptime into business-level signals like form delivery or WooCommerce orders, and whether alerts are confirmed from multiple regions before they fire.

Does Pingvera import Freshping monitors automatically?

No — there's no automated import. Adding a site takes a few minutes, about what adding a URL took on Freshping. Doing it before March 6, 2026 means the new monitoring already has history in place instead of a gap.

Originally published at pingvera.com.

Uptime green, orders zero — catching a WooCommerce store that stopped selling

Artem Meleshkin — Mon, 10 Aug 2026 18:15:30 +0000

The uptime monitor has been green all day. The status page shows 100%. Checkout loads, the cart adds up, the "Place order" button is right there. And the store has not sold anything in an hour, when it usually sells eight or nine orders in that window. Nothing in the classic monitoring stack will tell you that — because nothing in the classic monitoring stack is looking at orders. It's looking at pages loading. This is the gap, and it's exactly the gap real-time order events and an hourly baseline are built to close.

The question uptime monitoring actually answers

An uptime check does one thing, and it does it well: it requests a URL on a schedule and records whether the response came back and how fast. That answers "is the server reachable and responding correctly." It is a genuinely necessary check — a store that returns 500 or times out is obviously broken, and you want to know in seconds.

But "the server responded" and "the business is working" are different claims, and the gap between them is where a store quietly stops selling while every dashboard stays green. A handful of concrete ways a checkout keeps returning 200 while it stops converting:

The payment gateway is left in test mode. The checkout page renders identically. Card fields accept input. The order attempt fails or silently routes to a sandbox — nothing about that changes what an uptime probe sees.
A plugin or theme update breaks the checkout template. The page still loads with a 200. The "place order" button might be misplaced, disabled by a JS error, or simply not wired to the form submit anymore.
A webhook that confirms payment stops firing. The HTTP response for the checkout page itself never touches this at all — it's a background call between the payment processor and the store that an outside HTTP probe was never watching in the first place.
The order-creation pipeline breaks on the server. A conflicting plugin, a database error, a misconfigured order-status hook — the storefront renders fine because it's a completely separate code path from the one that actually writes the order.
Orders simply stop — no error anywhere, just nobody completing a purchase, which can be the checkout, the payment method, or something upstream like a broken ad campaign or an expired discount code loop. Whatever the cause, "nothing is happening" produces no error for anything to catch.

Every single one of these leaves the HTTP status code at 200. That is the blind spot, and it is not a small one: it is every failure that happens after the page has already loaded correctly.

Why polling can't see a business that stopped, even if you poll the right thing

You could imagine solving this by polling something order-related — hitting a "how many orders today" endpoint every five minutes. It would still be the wrong shape of tool, for two reasons.

First, polling has no memory of what's normal. A number by itself — "orders today: 14" — means nothing without knowing whether 14 by 3pm is a catastrophe or a great day for this particular store. Second, and more fundamentally, absence is not an event. An uptime check fails loudly: a timeout, a 500, a TLS handshake error — something happens that the monitor can catch. A store that stops selling produces no such moment. Nothing errors. Nothing times out. The silence just accumulates, one non-event at a time, and a system built to catch events has nothing to catch.

That's why Pingvera's WordPress/WooCommerce connector doesn't poll for orders — it reports them. The plugin sends an order.created event to the dashboard at the moment a checkout completes, with the order id, amount and currency (no customer personal data), plus order.failed when a payment attempt is declined. That turns "did anything happen" from a question you have to keep asking into a stream you can watch stop.

Watching a stream stop: the hourly baseline

A stream that stops is still not useful on its own — you need to know whether stopping is normal. A boutique selling three items a week has hours with zero orders as a matter of course; alerting on that would just be noise nobody trusts, and noisy alerts get muted, which defeats the entire point.

So the detector builds a baseline: for each store, it learns the normal order count by day of week and hour of day, from eight weeks of that store's own history. Tuesday at 2pm is compared against other Tuesdays at 2pm. A Saturday-heavy store is compared against its own Saturdays, not a flat average that would falsely flag its quiet Mondays every single week.

The condition that raises an incident is deliberately narrow:

the baseline for this store, this day of week, this hour, is at least 3 expected orders — so a slow store that rarely sells in a given hour never triggers a false alarm;
the actual order count in the last hour is zero;
the silence has held for 60 minutes — long enough to rule out an ordinary lull, short enough that you find out the same afternoon, not three days later.

And critically, this incident only makes sense — only means anything actionable — when it fires alongside a green uptime check and a checkout that's returning 200. That combination is the signal: the site works, and the business isn't. If uptime were also red, you wouldn't need a baseline to tell you something's wrong.

Uptime monitoring vs business observability

Neither column replaces the other. A store with only the left column can be losing every sale for a day and show a perfect uptime report. A store with only the right column has no idea if the server itself fell over. You want both watching, because each is structurally blind to what the other one exists to catch.

Why silence is worse than an error, not just harder to catch

It's tempting to think of "no orders" as a milder problem than "site down" because nothing is technically broken. In practice it's often worse, for a reason that has nothing to do with detection difficulty: WooCommerce's own notification system depends on orders existing. Order-confirmation emails, admin new-order notifications, anything triggered on order status — all of it fires off the order object. No order means no notification, from any source, to anyone. There is no native "you usually get 8 orders an hour and you got 0" alert, because the platform only reports things that happened, and a thing that stops happening isn't an event to it.

Compare that to an outright outage: the site is down, the client's phone starts ringing, the agency finds out from a friend, from Twitter, from an uptime alert. It's unpleasant but it's fast. A dead checkout that keeps returning 200 produces none of that pressure. It can run quietly for a day, a weekend, sometimes longer — the first anyone hears about it is the client asking why last month's revenue looks strange, at which point the money is already gone and there's no way to get those customers back.

What this looks like in practice

The order-events feed doesn't stand alone — it lands on the same per-site timeline as uptime incidents and deploy/update events, so when the anomaly fires you're not staring at a bare "0 orders" line with no context. You can see, on one timeline: orders arriving normally, then a plugin update, then the silence, then the incident 60 minutes in. The correlation between "what changed" and "what broke" is right there without cross-referencing three different tools. (More on that pairing in how a unified timeline puts the cause next to the effect.)

And this sits alongside the checks covered in reading failed-order spikes, stalls and silence and the daily checkout smoke test — together they cover the gateway-in-test-mode case, the broken-template case, and the "orders simply stopped" case from three different angles, rather than relying on any one signal to catch everything.

The uncomfortable summary

A green uptime dashboard tells you the server is fine. It has never told you, and structurally cannot tell you, whether anyone bought anything. The failure modes that leave a store selling nothing while returning 200 OK are common, not exotic — a test-mode gateway toggle, a template that shifted six pixels after an update, a webhook that stopped without an error. None of them show up as downtime. All of them show up as orders that should have happened and didn't.

This is not a request for more dashboards to check. It's the case for watching a different signal — the one the business actually cares about — with a baseline that knows what normal looks like for this specific store, at this specific hour.

Frequently asked questions

How can a store be broken if uptime monitoring shows 100%?

Because uptime checks answer "did the server respond," not "did the business work." A gateway left in test mode, a checkout template broken by an update, or a webhook that silently stopped firing all leave the HTTP response untouched — the page keeps returning 200 while nothing behind it functions.

What is an hourly baseline, and how many weeks of data does it need?

The store's own order volume, bucketed by day of week and hour, learned from eight weeks of its own history — so a Tuesday afternoon is judged against other Tuesday afternoons, not a flat average that would misfire on every quiet Monday.

Why does the detector wait 60 minutes before raising an incident?

To rule out ordinary variance. The alert only fires once the silence has held long enough to be a real signal against that store's own baseline — and only for hours where the baseline expects at least 3 orders, so slow stores don't get paged on a normal quiet hour.

Does this replace uptime monitoring?

No. Uptime, SSL, domain and checkout-page checks catch failures that change the HTTP response. Order-based anomaly detection catches the failures that don't. Each is blind to what the other is built to see, so you want both.

Originally published at pingvera.com.

The unified timeline — the deploy that broke checkout, next to the orders that stopped

Artem Meleshkin — Mon, 10 Aug 2026 11:13:37 +0000

The client's message is always some version of the same sentence: "orders stopped coming in, any idea why?" And the honest first move, every single time, is not to open the error log — it's to ask "what changed?" Nine incidents out of ten trace back to something that changed shortly before. The problem is that "what changed" usually lives in three different places: a deploy log, a plugin changelog nobody's watching, and your own memory of what you pushed on Tuesday. A unified timeline exists to collapse those three places into one line, so the cause is sitting right next to the effect instead of scattered across tabs you have to remember to open.

The debugging tax nobody puts on the invoice

Picture the ordinary version of this incident without a timeline. A client emails that orders have gone quiet. You open the uptime dashboard — green. You open WooCommerce — no obvious errors on the order list, because there's nothing to see, there just aren't any orders. You check the payment gateway settings — look fine at a glance. Then you remember, or a colleague remembers, or you go digging through a deploy log in a different tool: right, the WooCommerce plugin got updated Tuesday afternoon. That's forty-five minutes of cross-referencing to arrive at a fact that was true the entire time and simply wasn't visible from where you were looking.

That forty-five minutes is the debugging tax. It's not caused by the incident being hard — updating a plugin and breaking checkout is a common, almost boring failure mode. It's caused by the evidence for "what changed" and the evidence for "what broke" living in systems that don't talk to each other.

What "unified" actually means here

Pingvera's per-site timeline puts three kinds of signal on one shared clock:

Business events — order.created and order.failed, reported in real time by the WordPress/WooCommerce connector as checkouts complete, with the order id, amount, currency and status.
Deploys and updates — plugin, theme and core updates the connector observes on the site.
Incidents — uptime, SSL, domain, checkout monitoring and the order-drought anomaly detector, all reported by monitoring from outside the site.

None of that requires you to do anything differently — the connector reports what happens on the site, the monitors report what they observe from outside, and both land in the same place with the same clock. The value isn't in any one of those three streams; it's that they sit next to each other in the order they actually occurred.

A concrete sequence, on the timeline

Here's the shape of an actual afternoon, as it would appear on a site's timeline — not a hypothetical, this is the exact pattern that ends up in a client's inbox as "orders stopped, any idea why?":

Reading that top to bottom takes ten seconds, not forty-five minutes. Orders were flowing normally. A plugin update landed at 14:08. The order stream went silent starting at exactly that point. The anomaly detector confirmed it as a real incident 60 minutes later — the debounce window described in how the hourly baseline and 60-minute silence threshold work. Nobody had to remember the deploy happened. Nobody had to open a second tab to check when it happened. It's the line right above the incident.

To be precise about what this is and isn't: the timeline doesn't run a root-cause algorithm or declare "the 2.4.0 update caused this." It puts the two facts next to each other, in the order they happened, and lets the person reading it draw the obvious conclusion — which in this case takes about one glance.

Debugging with vs. without a shared timeline

Why this matters more once you're past one site

On a single site you manage yourself, "what changed" is mostly a memory exercise — you probably remember pushing an update on Tuesday. That falls apart fast once an agency is running a portfolio: thirty client sites, updates going out on different schedules, some of them handled by different team members, some plugins auto-updating on their own. Nobody holds "what changed on which site, and when" in their head across thirty sites. The timeline is where that gets held instead — automatically, per site, without anyone having to keep a change log by hand.

It also changes the shape of the client conversation. "We think the update on Tuesday caused it, we're checking" is a much better message to send at minute five than "we're investigating" is at minute forty-five — and it's true because the timeline made it obvious, not because someone got lucky remembering the right thing.

What this is not

Worth being precise here, because it's easy to over-promise on anything that touches the word "incident." The timeline observes and lays out — it does not act. Pingvera's agent is strictly one-way: it reports what it sees on the client's site and never receives commands, never deploys anything, never modifies anything on the client's machine. Nothing about the timeline changes that. It's a record you read, not a system that takes action on your behalf — the same principle that governs why the monitoring agent can't be told what to do.

The uncomfortable summary

Most client incidents aren't mysterious once you know what changed. The actual cost is almost always the time spent finding that out — hopping between a deploy log, an order list and an uptime dashboard that don't share a clock. Putting business events, deploys and incidents on one per-site timeline doesn't make incidents rarer. It makes the obvious explanation obvious immediately, instead of forty-five minutes later.

Frequently asked questions

What events actually appear on the unified timeline?

Business events from the WordPress/WooCommerce connector (order.created, order.failed, with amount, currency and status), deploy/update events, and monitoring incidents (uptime, SSL, domain, checkout, order-anomaly). All on the same shared clock, in the order they happened.

Is this an APM tool or a deployment tracker?

No. It doesn't instrument code or manage deploys — the connector reports updates and orders from inside the site, monitoring reports incidents from outside, and the timeline lays both on one shared clock for a person to read.

Does the timeline try to prove what caused an incident?

No. It lays out what happened, in order, and leaves the reading to the person looking at it. Pingvera observes and explains — it doesn't act on a client's site.

Why does this matter more for agencies than for a single site owner?

Because context is the first thing lost at scale. One person can usually remember what they changed on one site last week. Nobody remembers what changed on which of thirty client sites — the timeline holds that instead, automatically, per site.

Originally published at pingvera.com.

The monitoring agent that cannot be told what to do

Artem Meleshkin — Sun, 12 Jul 2026 21:17:15 +0000

Here is a design decision we made early, wrote into the architecture as an invariant, and have refused to revisit since: our agent accepts no commands. Not "we don't currently use that feature" — the hub has no way to tell an installed agent to do anything at all. No remote execution, no self-update, no "collect this for us right now". It sends data outward, and that is the entire surface.

This is not a limitation we are working around. It is the product. And it costs us features that customers ask for, which is exactly why it is worth explaining.

The uncomfortable arithmetic of remote control

Any tool that can update a plugin across fifty client sites is, by construction, a tool that can execute code on fifty client sites. Any dashboard that can restart a service on your server holds, somewhere, a credential that lets it in. This is not a flaw in those products — it is what they are for. You cannot automate a repair without the power to perform it.

But that power has an owner, and the owner has a login, and the login has a support team, and somewhere in that chain there is a version of the software with a bug in it. When the tool is compromised, the blast radius is not the tool. It is every machine the tool could reach.

The industry has already run this experiment at scale. In July 2021, attackers exploited a vulnerability in a widely used remote monitoring and management platform. They did not break into a single company — they broke into the thing that had access to the companies. Roughly sixty managed service providers were hit, and through them, an estimated 800 to 1,500 downstream businesses were encrypted in a single weekend, with a $70 million ransom demand attached.

Read that shape again, because it is the whole argument: the victims did nothing wrong. They had bought a well-known product from a serious vendor and installed it exactly as instructed. Their compromise arrived through the door they had deliberately, sensibly, contractually left open — the one that let their provider help them.

A tool with remote control over a thousand servers is not a convenience with a security caveat. It is a single door to a thousand servers, and everything else about it is a detail.

What we decided instead

We asked a narrower question than most monitoring vendors do. Not "what could we do for the customer if we had access?" — the answer to that is always "more" — but "what is the least access that still lets us tell the truth about whether their sites work?"

The answer turned out to be: none at all, in the inbound direction.

The host agent is one-way. It opens an outbound connection, streams metrics, and hangs up. There is no command channel. The message types for remote instructions exist in our protocol as dead code from an early draft — frozen, never sent, ignored by the agent — and we left them in only because removing them would break protocol compatibility for no gain.
The WordPress plugin has no inbound endpoints. It registers no REST routes and no AJAX handlers. It gathers diagnostics — core version, plugin state, whether the order pipeline is alive, whether mail is actually leaving — and posts them out. There is no URL on your site that our servers can call.
Updating the agent is your action, not ours. No self-update, no silent replacement. If a new version ships, we can tell you your agent is old — a log line, a badge in the dashboard — and that is where our involvement ends. You reinstall it, verifying the checksum, on your schedule.

The security property that falls out of this is simple enough to state in one sentence, which is the point: if our servers are compromised tomorrow, an attacker still cannot reach your machine through us. There is no path. Not a locked one, not a well-audited one — no path.

What this costs — and we will not pretend otherwise

A monitor that cannot act is a monitor that cannot save you at 3 a.m. We do not do any of this, and we will not:

These are genuinely useful. If you need them, use a maintenance platform that provides them — and be clear-eyed that you are trading a real amount of exposure for a real amount of convenience. That trade is legitimate. It is simply not the trade we make on your behalf without telling you.

What we do instead is the half that does not require the door: watch the site from outside from several regions at once, watch the business paths from inside the CMS — does the checkout still accept an order, does the contact form still deliver mail to the inbox, is the certificate about to expire, is the domain quietly running out — and tell you the moment any of it stops being true. The failures that matter most are silent ones, and none of them require us to hold a key to your server.

The part that is really about trust

Agencies are the ones who feel this most sharply, because they are not making the decision for themselves. When you install a tool on a client's server, you have quietly extended that client's trust to a third party they have never heard of and cannot audit. If it goes wrong, "the vendor had a vulnerability" is not a sentence that survives contact with the client.

So the honest version of our pitch is not that we are more secure than the alternatives. It is that we removed the category of risk instead of managing it. There is nothing to audit in our access model, because there is no access. That is a smaller promise than "we will keep your servers safe" — and it is one we can actually keep, on our worst day.

Questions people actually ask

Can Pingvera fix a problem it finds?

No, and it never will. We tell you; you fix it. That is the whole contract, and it is what makes the security property above possible.

Isn't a plugin inside WordPress the same kind of access?

Only if it listens. Ours does not: no REST routes, no AJAX endpoints, no inbound path from us to your site. It collects and posts outward. A compromise of our side cannot become a compromise of yours.

What if I want the automation?

Then take it — from a maintenance platform built for it — and let an independent monitor verify the result afterwards. One tool changes the system; the other checks that the change did not quietly break the checkout. Those are two different jobs, and there is a good argument for not handing both to the same vendor.

Originally published at pingvera.com.

How much to charge for website maintenance — and what to actually put in the plan

Artem Meleshkin — Sun, 12 Jul 2026 20:27:28 +0000

Every article about maintenance pricing gives you a range and leaves. The range is the easy part — you can find one in ten seconds, and it will be wide enough to be useless. The hard part is the conversation in month four, when nothing has broken, and the client asks what exactly they are paying for. Get the structure right and that conversation never happens. Get it wrong and no price is defensible.

Price the risk, not the hours

The most common mistake is pricing a care plan as a bucket of support hours. It feels fair and it quietly destroys the relationship, because it teaches the client to think in the wrong unit.

Sell hours, and every invoice invites an audit: did we really use two hours? A quiet month looks like a refund waiting to happen. You have made your own reliability into an argument against your fee.

Price the risk you absorb, and the unit changes. The client is not buying your time; they are buying the guarantee that their site keeps working and that someone competent is watching. In a quiet month you delivered exactly what they bought. That is a very different negotiation.

Which means the price should follow what breaking actually costs them:

Two clients with identical WordPress installs can legitimately pay very different amounts, and you can explain why in one sentence: "one of you loses a Tuesday, the other loses ten thousand dollars."

What actually belongs in the plan

The table stakes (everybody has these)

Backups — with restores you have actually tested. An untested backup is a rumour.
Updates — core, plugins, themes, with a check that the site still works afterwards.
Security — vulnerability watch, malware scanning.
Uptime monitoring — the box everyone ticks.

You cannot charge a premium for these. Every competitor lists them, most hosts throw in half of them, and the client assumes them. They are the cost of entry.

The differentiators (almost nobody has these)

Here is where a plan stops being a commodity, and it comes down to one shift: from watching the website to watching the business the website is doing.

Lead delivery, verified end to end. Not "the contact page loads" — an actual test submission that is then found in the mailbox. Because the form will show a green success message long after it stopped delivering anything, and neither WordPress nor any SMTP log will tell you otherwise.
Order acceptance, for stores. Order flow, failed-order spikes, gateways left in test mode. A store can return 200 OK for a week while taking exactly zero money.
Expiry watch. Domain and SSL. The two outages that agencies inflict on themselves, and the two that are unforgivable because they were on a calendar.
Integrity. Modified core files, injected redirects, an accidental noindex after a release.
A report the client reads. See below — this is the part that decides whether the retainer survives.

Notice what these have in common: they all fail silently. Which is exactly why they belong in a paid plan — nobody notices them missing until it is expensive, and nobody thanks you for them until you can show them.

A structure that holds up

Three tiers, each defined by what you take responsibility for, not by hours:

Two deliberate choices in that table. Small edits are included in every tier — they cost you little, they are the thing clients feel, and metering them poisons the relationship over twenty-dollar arguments. And the response window is a tier feature: it is the honest way to charge more, because it is the thing you are genuinely selling — how fast a human turns up.

The month-four problem

Here is the conversation that kills retainers. Four months in, nothing has broken. The client looks at the invoice and thinks: we're paying for nothing.

They are not wrong to think it. From where they sit, they have observed four months of a website working — the same website that, in their mental model, would probably have worked anyway. The value you delivered is entirely invisible. It is defined by absence.

There is exactly one instrument that fixes this, and it is not a better sales conversation. It is the monthly report — and specifically, a report that talks about prevention rather than activity:

Bad: "Uptime 99.98%. 12 plugins updated." (Numbers. So what?)
Good: "Your SSL certificate was due to expire on the 12th — renewed on the 3rd. Two plugins had published vulnerabilities; updated the same week. Your contact form was tested 720 times this month and delivered every time."

The second version reports the same month. It just makes the invisible visible: here is what would have gone wrong, here is why it didn't. A quiet month stops being an absence of work and becomes evidence of it.

And the report needs to be boringly reliable, because it is the product the client actually holds. If it arrives late, arrives empty, or arrives with numbers that changed since last time, you have undermined the one artefact that justifies the fee. (This is not theoretical — agencies publicly complain that their reporting tool "randomly" works.) Ours freezes the data into an immutable snapshot when the report is created, so the numbers a client sees in August are the numbers you sent in July.

Three pricing rules that survive contact with clients

Never sell "hours of maintenance". Sell responsibility for outcomes. Hours make you a contractor to be audited; outcomes make you a partner to be kept.
Charge more for the sites that would hurt more. And say so out loud — clients understand risk-based pricing instinctively. It's how they buy insurance.
Report prevention every single month, without being asked. The retainer is renewed by the report, not by the work. The work merely makes the report true.

Get those three right and the exact number matters far less than you think. Get them wrong and you will be haggled down to a commodity price for work that, when it finally fails, will be blamed on you anyway.

FAQ

How much should I charge for website maintenance?

Price the risk you absorb, not the hours you expect to spend. A brochure site and an e-commerce store are different products even on identical software. Build tiers around what you take responsibility for — availability, leads, orders, security — because hours invite the client to audit your time instead of valuing the outcome.

What should be included in a care plan?

Table stakes: backups with tested restores, updates, security, uptime. What makes it defensible: business-path monitoring — forms still delivering leads, stores still taking orders — plus a monthly report the client can actually read.

How do I justify the retainer in a month when nothing broke?

Report prevention, not activity. A quiet month is a result — but only if you can show what you were holding up: the certificate renewed before it expired, the vulnerable plugins patched, the form verified as still delivering. Without that record, a quiet month looks like a month of nothing.

Should hosting and maintenance be bundled?

They can be, and it raises perceived value — but keep the responsibilities distinct. Hosting is infrastructure you resell; maintenance is a promise you keep. When the host has an outage, the client calls you anyway — which argues for monitoring you control rather than the host's own status page.

Originally published at pingvera.com.

ManageWP alternative — what to use when the dashboard says "connected" and it isn't

Artem Meleshkin — Sun, 12 Jul 2026 20:26:35 +0000

Most "alternative" pages are written by people who never used the product they are attacking. So let's do this differently: no adjectives, just what agencies are publicly saying, why those specific failures happen, and an honest account of what we do and do not replace. Spoiler for the impatient: we are not a drop-in replacement for ManageWP, and if a competitor tells you they are, ask them where their backups live.

What people actually complain about

1. Sites disconnect, and the dashboard keeps showing green

This is the complaint, not one of several. It appears again and again in public reviews:

"Sites are always disconnected. Can't rely on it. Be carefull. You think everything is all right but in fact your sites are disconnected so not responding."WordPress.org review, 1★

"I am having a recurring issue where some of my sites keep getting disconnected, and when I check the managewp plugin is disabled… it is not a user disabling the plugin, I am 100% sure."WordPress.org support forum

An agency with over a hundred sites reports the same thing, and the thread has been alive for years — long enough that people are writing cron jobs to reactivate the plugin behind the platform's back.

Notice what the first quote actually describes. The problem is not that a site disconnected. The problem is that you believed you were covered and you were not. A monitoring tool that fails silently is worse than no monitoring, because it also sells you confidence.

2. Client reports work "randomly"

"Support tickets takes 3-4 days before getting answers… Generating pdf reports to customers is randomly working."WordPress.org review, 1★ — agency with 100+ sites, 6-year customer

Read that phrase again: randomly working. Client reporting is the thing agencies buy these platforms for — it is the artefact that justifies the retainer. If it works four months out of five, you cannot build a service promise on it.

This is worth stating clearly because it corrected our own assumptions. We used to think the industry complaint about reports was "too long, clients don't read them". It isn't. The complaint is that reports break: PDFs that arrive damaged, reports with empty data, reports that stop sending. Length is a design preference. A report that doesn't arrive is a broken promise to your client.

3. Support that answers in days — or never

"I had 1 site that wouldn't connect and i waited over 18 months for support to reply, then had to give up… I have several tickets in this state, waiting on a reply for over 1 year."WordPress.org support forum

"Support has been ghosting me for over a month. I've been a ManageWP customer for years. We have a lot of clients on their paid services."WordPress.org review, 1★

We are a small team, so we are not going to make grand claims about support SLAs we haven't proven. But we will say the obvious: when a platform's own users are writing workarounds because the vendor said the bug affects "only a small number of people", the product has stopped being maintained in any meaningful sense.

4. Updates that break the site you were protecting

"The update was apparently successful but when I tried accessing my site directly after that, I encountered a code 500 error… it appears it corrupted all my installed plugins, so hereon, I don't trust it."WordPress.org review, 2★

This one deserves a design comment rather than a jab. A tool that can push changes into a client's site can also break it. That risk is inherent to remote management, and it is exactly why our architecture refuses to take it: we never execute anything on a client's server. The plugin collects diagnostics and sends them out; we have no channel to run code, update plugins or touch files. It is not a missing feature — it is a boundary we designed in, so that the worst thing our tool can do to your client's site is nothing at all.

What an alternative actually has to get right

Strip away the feature lists and the complaints reduce to three requirements.

Monitoring that doesn't depend on a plugin staying alive

If your monitoring lives inside a plugin on the client's site, then a deactivated plugin, a broken update or a dead host takes your monitoring with it — precisely when you need it. External probing has no such failure mode: the prober sits outside, and a site that stops answering is the signal.

Our WordPress plugin exists too, but it does the opposite job: it sees what external checks cannot — a stalled WP-Cron, modified core files, vulnerable plugins. If it goes silent, the external layer is still watching. Two layers, and the failure of one does not blind the other.

Alerts you can believe

An alert nobody trusts is not a cheaper product, it is a broken one. We confirm from several regions before opening an incident — one probe having a bad ten seconds is not an outage — and noise suppression is on for every plan, including the free one, rather than sold as an upgrade.

Reports that always send, and always have data

We took the "randomly working" complaint literally when we rebuilt reporting. When you create a client report, the data is frozen into an immutable snapshot at that moment. The link the client opens next month renders from that snapshot, not from a live recalculation — so the numbers cannot drift, and a report cannot arrive empty because something upstream hiccupped. Delivery has retries and a visible history: you can see whether it sent, failed, or is still queued, instead of finding out from the client that nothing arrived.

The honest part: what we do not replace

ManageWP is a management platform. We are not.

So the honest recommendation is not "switch". It is: keep a maintenance platform for backups and updates, and move monitoring and client reporting to a stack that is not the same tool. One tool changes the system; the other verifies the result from outside. When they are the same tool, nobody is checking the checker — which is exactly how you end up with a dashboard confidently showing green over a site that has been disconnected for a week.

If you're evaluating right now

Three questions worth asking any candidate, ManageWP included:

If the plugin on my client's site dies, does your monitoring die with it? If yes, your monitoring is only as reliable as the least reliable site you manage.
How many locations confirm an outage before you alert me? If the answer is one, budget for false alarms — and for the day your team stops reading them.
What does a client report do when the data pipeline fails? Arrives empty, doesn't arrive, or refuses to be created? Only the third answer is safe.

FAQ

Is Pingvera a drop-in replacement for ManageWP?

No. ManageWP does backups, bulk updates and site management; we do not — we monitor. If you rely on it for backups and one-click updates, you need those from somewhere. What we replace is the part that keeps failing: trustworthy monitoring and client reports that actually arrive.

Why do ManageWP sites keep disconnecting?

Users report the worker plugin deactivating itself or losing connection while the dashboard keeps showing the site as fine. The forum thread has been running for years, with agencies writing cron workarounds. The dangerous part is not the disconnection — it is the dashboard showing green while blind.

What should an agency look for in an alternative?

Monitoring that survives independently of a plugin on the client's site; multi-region confirmation so a single blip doesn't page you; and client reports that always send with data in them.

Can I run both?

That's what we'd recommend. Keep the management platform for backups and updates; put monitoring and reporting on a separate stack. One tool changes the system, the other verifies it from outside.

Originally published at pingvera.com.

Elementor form not sending email — what the docs admit, and what nobody checks

Artem Meleshkin — Sun, 12 Jul 2026 20:25:51 +0000

Elementor's own help pages are unusually honest about this, and the honesty is the whole answer. Two sentences from their troubleshooting docs explain most missing-email cases before you touch a single setting.

Straight from the documentation

"Elementor uses WordPress' wp_mail function to send emails. Your web host takes the sent email, processes it, and sends it."

"The wp_mail function uses the PHP send_mail function by default. But if it is disabled on that server, then email won't send."elementor.com — Server errors

And, on why hosts disable it:

"Web hosting servers can deactivate the PHP function responsible for email transmission… a precautionary measure meant to prevent the misuse of the server for spamming purposes."elementor.com

So: the form hands the email to WordPress, WordPress hands it to the host, and the host may have quietly closed that door on purpose. Nothing in the front end will tell you. The visitor sees the success message; the widget has done everything it can do.

The Elementor-specific causes, in order of frequency

1. There is no Email action

The most embarrassing and the most common. Elementor forms only send mail if you added the Email action under Actions After Submit. Forget it, or lose it while duplicating a template, and the form works perfectly — collects the submission, shows a success message — and emails nobody. Everything looks right except the part you cannot see.

2. The From address is not your domain

Elementor's docs are direct about this: set the form's From address to the same domain as your website, and put the visitor's address in Reply-To. If your site is example.com and your From is the visitor's gmail.com address, you are asking a mail server to accept a message claiming to be from a domain you do not own, sent from an IP you do not own. Modern receivers call that spoofing and treat it accordingly.

3. It went to spam

Elementor's own documentation flags this, including the reason:

"These emails may end up in the spam folder, especially now that providers like Gmail are increasingly strict about email reputation and authentication."elementor.com

Unauthenticated mail from a shared hosting IP is a worse and worse bet every year. Every log will say the mail was sent. It was. It is in Junk.

4. The email arrives — and it's empty

A peculiar one, and worth knowing: if a form field has no ID, its value will not appear in the email when the [all-fields] shortcode is used. So you receive a notification with the fields you actually needed missing. The form works, the email works, the lead is unusable.

5. A plugin or theme conflict after an update

Elementor's troubleshooting suggests exactly what you would expect — disable everything except Elementor and Elementor Pro, switch to a default theme — which tells you how often an update to something unrelated takes the form's submit handler down with it.

The one thing Elementor does better than its rivals

Submissions are stored by default. The Collect Submissions action is on out of the box, entries go into the database, and you can view them under Elementor → Submissions and export to CSV.

That is a genuinely better default than Contact Form 7 (which stores nothing, and whose docs warn you may "lose important messages forever") or WPForms Lite (which does not store entries without a paid license). If mail breaks on an Elementor site, the lead is still recorded.

But notice what it does and does not solve. The lead is preserved. Nobody is notified. Your client is still not calling that customer back, because nothing told them there was a customer to call. A lead sitting unread in a dashboard for three weeks is, commercially, a lost lead with better bookkeeping.

The fix

Send through a real mail service — an SMTP plugin or Elementor's own sending product — with SPF, DKIM and DMARC aligned to your domain. This is the fix for most cases, because it stops the message being anonymous mail from a shared IP.
From = your domain. Visitor = Reply-To. Non-negotiable.
Confirm the Email action exists in Actions After Submit — and that the recipient address is right.
Give every field an ID, so [all-fields] renders the whole lead.
Check Submissions to separate the two questions: if entries are landing there, the form is fine and only the mail is broken. That is a genuinely useful diagnostic.

And then, next month, it breaks again

Every fix on that list is a point-in-time repair. The chain has many links — plugin, WordPress, SMTP credentials, DNS records, the host's outbound policy, the recipient's spam filter — and each of them can change without anyone touching your site. An SMTP plugin update. A rotated API key. A stricter policy at the client's mail provider. A DNS change that breaks DKIM alignment.

When it breaks, the form will keep showing the success message. Submissions will keep filling up. And the first person to notice will be your client, weeks later, asking why nobody replied to their enquiry — the worst possible way for this to surface.

What actually verifies delivery

Not a log entry. A "delivered" status from a sending service only means that service handed the message to the recipient's mail server; it says nothing about inbox versus junk. The only proof that a lead reaches a human is to send one and then find it in the mailbox.

That is what our form check does: on a schedule it submits a synthetic lead through the real form, with a unique marker in the body, then looks for that marker in a monitored inbox over IMAP. Arrives → the whole chain works, plugin to spam filter. Doesn't arrive → you get an alert, while the client is still blissfully unaware there was anything to know.

It is the least clever monitoring we do. It is also the only kind that could have caught any of the failures in this article.

FAQ

Why is my Elementor form not sending email?

Elementor's docs state it uses WordPress's wp_mail function, which uses PHP's mail function by default — and if the host disabled it, email will not send. Other causes: no Email action added under Actions After Submit, a From address outside your domain, or the message being filtered into spam.

Why does the email arrive empty?

Usually a form field without an ID. Elementor's docs warn that without a valid ID, the field value will not appear in the email when [all-fields] is used — so the notification arrives with the important fields missing.

Does Elementor store submissions?

Yes — Collect Submissions is enabled by default, entries go to the database and can be exported to CSV. That means a failed email doesn't lose the lead. It does mean nobody gets notified about it.

Does a "delivered" status prove the client got the lead?

No. It means the sending service handed the message to the recipient's mail server. It says nothing about inbox versus junk. The only certainty is submitting a test lead and verifying it appears in the real mailbox.

Originally published at pingvera.com.

WPForms not sending email notifications — three ways leads vanish quietly

Artem Meleshkin — Sun, 12 Jul 2026 20:24:58 +0000

WPForms is a good plugin, and most "not sending email" advice for it is the same generic SMTP checklist you have already read. So let's skip that and start with the three failures that are specific to WPForms, all of which share one property: the visitor sees a success message, and you receive nothing.

Failure 1: the entry was marked as spam — so no email is sent

This is the one that surprises people, and it is documented behaviour. From WPForms' own documentation on spam entries:

"After enabling this option, the form will allow all submissions (including spam entries) instead of blocking them. However, form notification emails won't be delivered if an entry is identified as spam."wpforms.com — Viewing and Managing Spam Entries

Read the consequence carefully. A real customer fills in your client's form. Akismet or the built-in anti-spam decides, on some heuristic, that they are a bot. The customer sees "Thanks for contacting us!" and goes about their day, satisfied. The entry lands in a Spam folder inside WordPress. No notification is sent to anyone. Nobody knows this happened unless someone thinks to open the spam tab.

Marking the entry "Not Spam" afterwards does send the notification — retroactively, once you have found it. Which requires knowing to look.

Failure 2: background sending, and a queue that stopped

WPForms has an option called Optimize Email Sending. Instead of sending during the submission request, it queues the notification through Action Scheduler and sends it in the background. Faster form, better user experience — with a dependency most people never think about: WP-Cron.

WordPress's scheduler is not a real cron. It fires when someone visits the site. On a low-traffic client site — exactly the kind of site whose owner is anxious about enquiries — the queue can sit for a long time. If Action Scheduler is unhealthy or WP-Cron is disabled without a real cron replacement, queued notifications may never go out at all.

The form still says "success", because from the form's point of view it did its job: it put the email in a queue. WPForms' own troubleshooting docs suggest turning this option off while diagnosing missing notifications — which tells you how often it is the culprit. And it is a good reminder that a stalled WP-Cron breaks far more than plugin updates.

Failure 3: on Lite, the lead does not exist anywhere else

"WPForms does not store entries without a paid license, but you can back them up remotely using Lite Connect… Since WPForms Lite doesn't save entries to your WordPress database, Lite Connect gives you a place to store them safely off your site."wpforms.com — Lite Connect

On Lite, the email is the delivery mechanism. There is no database copy to fall back on. If the notification fails for any of the reasons above, the enquiry is gone — no entry, no record, no way to know it ever happened. (Lite Connect keeps an off-site backup, but restoring it into your dashboard requires upgrading.)

This matters for agencies: a client on Lite who says "we've had no enquiries for a month" may have had thirty, all of which evaporated.

The usual suspects, briefly

These apply to every WordPress form plugin, WPForms included, and they are well covered elsewhere — so, briefly:

No SMTP. WPForms sends via wp_mail(), which by default hands off to PHP mail() on your host. Unauthenticated, unaligned with SPF or DKIM, from a shared IP. Modern mail providers filter or drop that.
From address outside your domain. WPForms' docs ask for a domain-specific From address. The visitor's address goes in Reply-To, never From.
Host blocks or throttles mail(). Common, and deliberate — hosts do it to stop compromised sites spamming.
Notification switched off or gated by conditional logic. Check the notification is Active and the conditions actually match.
It arrived in the spam folder of the recipient. Every log says "sent". The client says "nothing".

Why "the SMTP log says Sent" is not an answer

People reach for an email log and feel safe. Here is what a log actually certifies, in WP Mail SMTP's own words:

Sent — "The email was sent successfully. This status does not tell you whether the email was delivered."wpmailsmtp.com — How to View Email Logs

There is a Confirmed status, but it only exists for mailers with delivery webhooks, and even then it means the provider handed the message to the recipient's mail server. It does not mean the message is in the inbox rather than the junk folder, and it certainly does not mean a human saw it.

So the honest hierarchy of what each tool proves:

The only check that closes the loop

There is exactly one way to know that a lead reaches a human: send one, and then look in the mailbox for it.

That is what our form monitoring does. On a schedule it submits a synthetic lead through the real form, with a unique marker in the body, and then searches a monitored mailbox over IMAP for that marker. If it turns up, the entire chain is proven end to end — the plugin, the anti-spam rules, wp_mail(), SMTP authentication, the recipient's filters. If it doesn't turn up in the expected window, you get an alert.

It is not a clever check. It is the check a careful person would run by hand, if a careful person were willing to do it every hour and never forget. The reason it matters is that none of the other signals in this article can catch a spam-flagged entry, a stalled queue, or a message quietly filed into Junk — and those are exactly the failures that cost your client a month of enquiries before anyone notices.

FAQ

Why does WPForms show success but send no notification?

Three WPForms-specific reasons: the entry was flagged as spam (documentation states notification emails are not delivered for spam entries, while the visitor still sees success); background sending queued the email and the queue stalled; or the mail was sent unauthenticated and dropped by the receiving server.

Does WPForms Lite store entries?

No — entries are not stored without a paid license. Lite Connect backs them up remotely, but restoring into the dashboard requires upgrading. On Lite, a failed email means the lead is gone.

What is Optimize Email Sending?

It queues notifications through Action Scheduler instead of sending during the request. If WP-Cron or Action Scheduler is unhealthy — common on low-traffic sites — queued emails can be badly delayed or never sent, while the form reports success.

Does an SMTP log prove the lead arrived?

No. WP Mail SMTP's docs state the Sent status "does not tell you whether the email was delivered". Confirmed exists only for mailers with webhooks, and means handoff to the recipient's server — not inbox versus junk.

Originally published at pingvera.com.

WooCommerce failed orders — what a spike, a stall and a silence each mean

Artem Meleshkin — Sun, 12 Jul 2026 20:24:05 +0000

A client emails: "we've got hundreds of failed orders, is the payment gateway broken?" The gateway is almost certainly fine. What is happening is worse, it is documented by WooCommerce itself, and the damage will outlast the attack by months. Let's read the three patterns properly — because each one means something completely different, and two of them are invisible in the reports your client actually looks at.

First, what "failed" actually means

WooCommerce is precise about this, and the distinction matters for everything below:

Pending payment — "The order has been received, but no payment has been made." The customer hasn't paid yet; often they are mid-flow, or wandered off.
Failed — "The customer's payment failed or was declined, and no payment has been successfully made." A payment was attempted and rejected.

So a failed order requires someone to have reached the payment step and been turned down. That single fact is what lets you diagnose all three patterns.

Pattern 1: a spike of failed orders — you're being used to test stolen cards

WooCommerce has an entire document about this, which tells you how common it is:

"Card testing is a type of fraud where the someone obtains a large amount of stolen credit card data, and then attempts to determine which of those cards are valid… multiple low-value purchases, each with a different card, to avoid detection."

The sign to watch for: "a large increase in the number of orders being assigned the Failed status" — hundreds or thousands within a short timeframe.woocommerce.com — preventing and responding to card testing attacks

Your client's checkout is being used as a validation service for a batch of stolen cards. The bots don't want the product. They want to know which numbers still work, so they can be sold or spent elsewhere. WooCommerce's own developer blog notes the attacks now hit the Store API checkout endpoint directly, rotating through IPs — "100 checkouts/minute, all from different IPs".

"But nothing was actually charged, so what's the harm?"

This is where store owners — and, honestly, a lot of agencies — get it wrong. The failed payments are not the damage. They are the exhaust.

Your decline rate is now poisoned — permanently. Stripe's documentation states that an elevated decline rate persists after the attack ends: card issuers have learned to distrust this merchant. Meaning your client's real customers start getting declined, weeks later, for no reason they will ever understand.
Some cards work. Those become real charges to real victims, who file chargebacks. Disputes cost fees and count against you.
Fees may not come back. WooCommerce's own guidance notes the payment provider "still may not refund the transactions fees for those transactions" even after you refund the fraudulent payments.
PayPal can simply switch you off. Their Payflow carding-prevention module monitors for high declines and, when thresholds are hit, blocks the account and declines all transactions until it is manually unblocked. And PayPal states plainly that merchants "are responsible for any transactional fees imposed by PayPal or their bank that result from carding attacks".
Card-network monitoring programs. Sustained dispute and fraud ratios pull merchants into Visa and Mastercard monitoring programs, where fines run into five and six figures.
Your domain's email reputation takes friendly fire. WooCommerce sends a failed-order notification to the "customer" too. Those are stolen identities and junk addresses — so your client's mail server sprays hundreds of undeliverable notifications, and the bounce rate does what bounce rates do to sender reputation. The same domain that also sends order confirmations to real buyers.

So the answer to "nothing was charged, what's the harm" is: your client's ability to accept money in the future has just been degraded, and they will feel it long after the failed orders stop appearing.

The part that makes this genuinely dangerous

Here is the fact that turns an incident into a catastrophe. From WooCommerce's Analytics documentation:

"Pending payment, Cancelled and Failed order statuses are excluded [from Analytics] while Processing, On hold, and Completed order statuses are included."woocommerce.com — WooCommerce Analytics

Read that again with the attack in mind. Hundreds of failed orders are pouring in — and the store's revenue reports show nothing at all. The one screen the owner checks is, by design, blind to exactly this event. The only native signal is a flood of individual "failed order" emails, one per attempt, which is precisely the kind of noise a busy person mutes or filters into a folder.

And the built-in defence is off. WooCommerce's Store API rate limiting is disabled by default; a strict limit on the place-order endpoint only arrived in version 9.6 and must be turned on by hand. Their own blog admits IP-based limiting isn't enough against rotating IPs anyway.

Pattern 2: a rise in pending — the gateway can't talk back

A different shape entirely: orders pile up in pending payment rather than failed. That is not a decline problem, because declines produce failures. It means the loop between the payment provider and the site is broken — most commonly an undelivered webhook. The customer paid; the provider took the money; the site never heard back.

This one has teeth because of a default nobody remembers: Hold stock, 60 minutes out of the box. A pending order that isn't confirmed within that window is automatically cancelled and its stock released. So the sequence is: customer pays → webhook never lands → order sits pending → an hour later WooCommerce quietly cancels it. The money is at the payment provider. The order is gone from the store. Nobody is looking for it.

Pattern 3: silence — the pattern everyone misreads

Zero failed orders. Zero orders. A calm, clean order list.

Owners read this as "quiet week". It is often the most expensive state of the three, and here is the logic that proves it: an order cannot become failed if the customer never reaches the payment step. No orders and no failures means nobody is even getting as far as paying. The likely causes are the ones WooCommerce lists in its own troubleshooting: a plugin or theme update that broke the checkout, expired API keys, a payment method that got switched off, a gateway left in test mode.

And the cruel part: because there are no orders, there are no order emails either. The absence of bad news looks exactly like a peaceful day. There is no native mechanism in WooCommerce that tells you "no orders for three days, and you usually get twelve" — the system only reports things that happen. A thing that stops happening is not an event.

Reading the patterns

Notice the column on the right. Every failure mode in this table is invisible in the report your client trusts. Only the last row shows up — the one where nothing is wrong.

What monitoring this actually looks like

You do not need machine learning. You need two numbers, compared against the store's own history — and this is exactly what our WooCommerce checks do from inside the store:

Failed-order share against the store's own baseline. Not an absolute threshold — a store with cash-on-delivery or aggressive fraud rules lives with a steady failure rate, and alerting on that would be noise. We compare the last 24 hours against the same store's seven-day norm, with a floor of three failures so that statistics mean something. Three times the usual rate → critical. That fires on a card-testing attack within the hour, long before anyone opens the order list.
Order drought against the store's own baseline. Zero orders in 24 hours is only a signal if this store normally sells: we require an average of at least three orders a day over the previous fortnight before we say a word. A store doing two orders a week never gets woken up.

Plus the checks that catch the cause rather than the symptom: is a live payment gateway sitting in test mode, does the checkout page still render, and a daily smoke run of the order pipeline that proves an order can still be created at all.

The uncomfortable summary

WooCommerce will happily email your client three hundred times while bots grind stolen cards through their checkout, and show a perfectly clean revenue dashboard the whole time. It will let a paid order be silently cancelled because a webhook didn't land. And it will never, ever tell anyone that the orders stopped.

None of that is a bug — the platform reports events, and these are non-events, absences, and statuses it deliberately excludes from reports. But if you are the agency whose client's decline rate is now permanently worse, "it wasn't technically a bug" is not a conversation you want to be having.

FAQ

Why does my store suddenly have hundreds of failed orders?

Almost always card testing. WooCommerce documents it: attackers with stolen card data use a store's checkout to find which cards still work, making many low-value attempts. Their stated tell is "a large increase in the number of orders being assigned the Failed status" — hundreds or thousands in a short timeframe.

Is it harmful if all the payments failed?

Yes, and the damage outlives the attack. Stripe states the elevated decline rate persists afterwards — your real customers start getting declined. Some cards work and become chargebacks. Fees on fraudulent payments may not be refunded. PayPal's Payflow carding module can block the account entirely. And card-network monitoring programs carry fines into six figures.

Does WooCommerce Analytics show failed orders?

No — Pending payment, Cancelled and Failed are excluded by default. A card-testing attack producing hundreds of failed orders is invisible in the revenue reports the owner actually reads.

What does it mean when orders drop to zero?

Usually a dead checkout. An order can't be marked failed if nobody reaches payment — so no orders and no failures means something broke earlier. And with no orders, there are no emails either: silence looks exactly like a quiet week.

Originally published at pingvera.com.

WP Umbrella alternative — when what you needed was monitoring, not maintenance

Artem Meleshkin — Sun, 12 Jul 2026 20:22:23 +0000

Let's start where most competitor pages won't: WP Umbrella is a good product, and its users mostly like it. We went looking for a pile of angry reviews to quote and didn't find one — the ratings are high, people praise the interface and the support. So this page is not going to pretend otherwise. What we will do is answer the question people are actually typing into Google: if I'm looking for an alternative, what am I missing?

The one complaint its users really do make

There is a recurring theme in the negative reviews, and it isn't about quality:

"Today I check my site and notice the plugin's main screen showing a banner that says Your trial is over. Go Premium. Basically the free version is useless… The plugin description mentions all these great features little you know that those are all paid features."WordPress.org review, 3★

"It's only a 14-day trial, and after that, you pay high monthly fees… And it's only a demo, it's not free at all."WordPress.org review, 1★

There is no free tier. You get 14 days, then the features stop. For a freelancer with three client sites, or an agency wanting to try monitoring on a couple of projects before committing the whole portfolio, that is a real wall.

Our answer is boring and specific: free for up to 5 sites, permanently, with one-minute checks — not a trial, not a demo, not a countdown banner. We would rather you run five sites on us for a year and never pay than have you discover on day 15 that the thing you built a workflow around has switched itself off.

The deeper difference: what each tool is for

WP Umbrella is a WordPress maintenance platform. Its centre of gravity is: keep the CMS updated, backed up, patched, and produce a report about that work.

We are a monitoring service. Our centre of gravity is: does the site still work — not as a CMS, but as a business — and will you know before the client does?

That distinction sounds abstract until you look at what breaks in the real world. Here is a review of a similar management tool, from an agency owner:

"one of my site's clients was wondering why he was getting no response to a recent sale he announced on his site — and when he went to go check, he realized his store was gone completely! That's because the WooCommerce plugin had been deactivated somehow."WordPress.org review of a WordPress management tool, 2★

The site was up the entire time. Every uptime check would have passed. The maintenance platform had done its job — plugins updated, backups taken — and the store was silently dead. This is the gap. It is not a bug in anyone's product; it is a category boundary. Maintenance tools watch the platform. Nobody was watching the money.

What we monitor that a maintenance platform doesn't

Form delivery, end to end. Not "did the form page load", but: we submit a test lead with a unique marker and then find it in the mailbox. A form that silently stopped delivering is the most expensive failure a brochure site has, and it returns 200 the whole time.
WooCommerce orders, from inside. Order flow against the store's own baseline, failed-order spikes, a live gateway left in sandbox mode, a daily smoke run of the order pipeline.
Availability from several regions, with quorum. One probe having a bad ten seconds is not an outage — and a monitor that pages you for it will be muted within a month. Confirmation and noise suppression are on for every plan, free included.
WordPress health from inside. Stalled WP-Cron, modified core files, mail going out through PHP-mail, autoload bloat, fresh PHP fatals.
Domain and SSL expiry, broken links, accidental noindex, suspicious redirects. The self-inflicted outages.

What we don't do — and won't

If you switch to us expecting a maintenance platform, you will be disappointed, so let's be blunt about the shape of the hole:

The "by design" on updates deserves a sentence. We never execute anything on a client's server — no remote updates, no remote exec, no self-updating agent. The agent sends data out and that is the only direction traffic flows. It costs us a feature list; it buys the client a guarantee that the worst our tool can do to their site is nothing at all. After reading enough reviews that begin "the update was apparently successful but then the site returned a 500", we think that is the right trade.

So: alternative, or addition?

Replace WP Umbrella with us if your portfolio isn't WordPress-only; if what you actually need is monitoring and client reporting rather than update automation; if you want to start free rather than start a countdown; or if your clients' revenue depends on forms and checkouts that nobody is currently watching.

Run both if you're a WordPress agency that genuinely needs backups and safe updates. WP Umbrella performs the maintenance; we verify from outside that the site, its forms and its checkout still work after that maintenance. That is not redundancy. One tool changes the system, the other checks the result — and the day an update quietly deactivates WooCommerce, the second one is what saves the client relationship.

FAQ

Does WP Umbrella have a free plan?

No — a 14-day trial, after which the plugin's features stop working. It's the single most common complaint in its negative reviews: users install from the WordPress directory expecting a free tier and find a trial.

Is Pingvera a replacement for WP Umbrella?

Not a full one. WP Umbrella does backups, safe updates and vulnerability management; we do none of those and never will — our agent never executes anything on a client's server. We replace the monitoring and client-reporting half, and go deeper there: multi-region availability, form delivery, WooCommerce orders, WordPress health from inside.

What does WP Umbrella not monitor?

The business-critical paths: whether a form still delivers leads, whether a store still accepts orders, whether a payment gateway is stuck in test mode. It watches WordPress the platform, not the site as a business.

Can I use both?

Yes, and for a WordPress-only agency that's the strongest setup: WP Umbrella maintains, an independent monitoring layer verifies from outside that everything still works after the maintenance.

Originally published at pingvera.com.

Contact Form 7 not sending email — the green checkmark that means nothing

Artem Meleshkin — Sun, 12 Jul 2026 20:21:29 +0000

The form submits. The green message appears. The email never arrives. Before you start disabling plugins, understand what that green message actually certifies — because the answer explains the entire problem, and it comes from CF7's own documentation.

What the green border actually means

Contact Form 7 sends mail through WordPress's wp_mail() function. The green success message means exactly one thing: that function returned true. WordPress core is unusually candid about what that is worth:

"A true return value does not automatically mean that the user received the email successfully. It just only means that the method used was able to process the request without any errors."WordPress developer reference, wp_mail()

And CF7's own FAQ, answering "I see a green border response but I never receive a mail", is even more direct:

"Showing the green border message means that the PHP function for sending the mail has certainly completed successfully. So if you can't receive the mail, it's highly possible that the mail has been kidnapped or killed after that… Spam filter often causes this kind of problem."contactform7.com FAQ

Kidnapped or killed. That is the plugin author telling you, in writing, that the success message covers only the first link of a chain with at least four links in it. Everything after the handoff is invisible to CF7 — and therefore to you.

Where the chain actually breaks

1. No SMTP — the mail is unauthenticated

By default wp_mail() ends up calling PHP's mail(), which hands the message to the mail transport on your web host. That message carries no SPF alignment, no DKIM signature, and comes from a shared hosting IP with an unknown reputation. Gmail and Outlook increasingly treat that as spam — or drop it outright, without a bounce. From the site's perspective, everything succeeded.

2. The From address doesn't belong to your domain

An old and very persistent tutorial habit: putting [your-email] in the From field on the Mail tab, so replies "come from the visitor". To a receiving mail server that is a domain you do not own, sending from an IP you do not own — textbook spoofing. Modern CF7 flags this itself as a configuration error ("Sender email address does not belong to the site domain"), and its documentation is explicit that the From address should belong to the same domain as the web site. The visitor's address belongs in Reply-To, not From.

3. The host disabled or throttled `mail()`

Many hosts disable the PHP mail function entirely, or cap outbound mail, specifically to stop compromised sites from spamming. CF7 will show a red border if wp_mail() returns false — but a throttled or silently discarded message can still return true.

4. Anti-spam ate the submission — and you can't tell

This one is genuinely tricky. If Akismet, reCAPTCHA or the disallowed-words list rejects a submission, CF7 shows an orange border. But here is the design decision, stated openly in their FAQ: CF7 deliberately uses the same message for a mail failure and for a spam rejection, on the reasoning that you should not tell a spammer they have been detected.

Sensible for spam. Terrible for you: from the front end, "your mail configuration is broken" and "our anti-spam is silently eating real client leads" look identical. reCAPTCHA v3, in particular, scores submissions invisibly — a badly tuned threshold will quietly reject real humans forever.

5. It arrived — in the spam folder

The most common ending, and the hardest to prove. The email was delivered to the recipient's server, accepted, filtered, and dropped into Junk, where nobody looks. Every log in your stack says "sent". The client says "we get no enquiries".

The fix, in order

Install an SMTP plugin and authenticate properly. Send through a real mail service with SPF, DKIM and DMARC aligned to your domain. This single change fixes the majority of cases.
Put your own domain in the From field. info@yourdomain.com, not the visitor's address. Visitor goes in Reply-To.
Install Flamingo. CF7 states plainly that it "doesn't store submitted messages anywhere. Therefore, you may lose important messages forever". Flamingo (same author) saves submissions to the database. It does not fix delivery — but it converts a permanently lost lead into a lead you can still find.
Turn on spam logging to find out whether anti-spam is the one rejecting your submissions, since the front-end message won't tell you.
Check the recipient's spam folder — and, if the recipient is on a corporate mail system, ask their admin to check the quarantine.

And now the real problem

Suppose you did all five. The form works today. You tested it, the email arrived, you closed the ticket.

Six weeks from now, one of these will happen: the SMTP plugin gets an update that breaks authentication; the mail service rotates a key; the host tightens outbound limits; the client's IT department turns on a stricter spam policy; a plugin update changes the From header. The form will keep showing the green message. Nobody will notice for weeks — until the client asks why enquiries have dried up, and you get to explain that you weren't watching.

This is not hypothetical, it is the default outcome, because none of the standard tools verify delivery:

What actually verifies delivery

Only one thing: submitting a real test lead and then finding it in a real mailbox. Not a function return value, not an SMTP acknowledgement, not a provider's report — the message, in the inbox, with your own eyes (or a machine's).

That is what our form check does. On a schedule, it submits a synthetic lead through the form with a unique marker in the body, and then looks for that marker in a monitored mailbox over IMAP. If the message arrives, the whole chain works — plugin, wp_mail(), SMTP, authentication, the recipient's spam filter. If it doesn't arrive within the window, you get an alert while the client is still happily unaware.

It is deliberately the least clever check we have: it does exactly what a careful human would do, except it does it every hour and never forgets. And it is the only check that can catch the failure mode CF7's own author describes — mail that was kidnapped and killed somewhere after the green checkmark.

FAQ

Why does CF7 show a green message but no email arrives?

The green border only means wp_mail() returned true — the request processed without an error. WordPress core states that a true return does not mean the email was received. CF7's FAQ says the mail may have been "kidnapped or killed" after that, most often by a spam filter.

Does Contact Form 7 store submissions?

No. Its own docs warn you may "lose important messages forever" if mail breaks. Flamingo saves submissions to the database — turning a lost lead into a delayed one.

What does the orange border mean?

A spam module (Akismet, reCAPTCHA, disallowed list) blocked the submission. CF7 deliberately shows the same message for a mail failure and a spam rejection, so from the front end you cannot tell which one is eating your leads.

How do I know the form still works without testing by hand?

Monitor delivery end to end: submit a test lead with a unique marker on a schedule, then verify it arrives in the mailbox. That is the only check covering the whole chain, including the receiving spam filter.

Originally published at pingvera.com.

WordPress cron not running — the scheduler that only works when somebody visits

Artem Meleshkin — Sun, 12 Jul 2026 20:20:36 +0000

WP-Cron is the most misunderstood component in WordPress, and the misunderstanding is baked into its name. It is not cron. It does not run on a schedule. It runs when someone loads a page — and if nobody loads a page, nothing happens. On the quiet client sites that most depend on automation, that is a slow, silent, invisible failure.

How WP-Cron actually works

Real cron is a daemon: the operating system wakes it up at the appointed minute whether or not anyone is watching. WP-Cron is a checklist that WordPress glances at during a page request. Someone visits the site, WordPress asks "is anything overdue?", and if so it fires those tasks — during that visitor's request.

Consequences fall out immediately:

No traffic, no scheduler. A B2B brochure site with forty visits a day runs its "hourly" jobs whenever someone happens to show up. Overnight, nothing runs at all.
Precision is a fiction. A job scheduled for 03:00 runs at the first page load after 03:00 — which might be 09:12.
Your visitor pays for it. Heavy scheduled work executes inside a real person's page request. They wait; the job runs.

This is why the standard advice is to turn WP-Cron off and use a real cron. And it is also where the most common catastrophe happens.

The mistake that kills automation silently

Someone reads that advice, opens wp-config.php, and adds:

define('DISABLE_WP_CRON', true);
Then they get distracted, or they hand the site to someone else, or they assume the host "does cron". The second half — actually scheduling the server to call wp-cron.php — never happens.

The result: the scheduler is now completely dead, and WordPress will never mention it again. No warning banner, no email, no log entry. The site serves pages beautifully. Backups stop. Scheduled posts never publish. Update checks stop. And nobody finds out for months — typically when the client asks why the newsletter didn't go out, or when you go looking for a backup that does not exist.

The correct pattern is both halves:

wp-config.php

define('DISABLE_WP_CRON', true);

server crontab — every 5 minutes

*/5 * * * * curl -s https://example.com/wp-cron.php?doing_wp_cron > /dev/null

or, better, via WP-CLI

*/5 * * * * cd /var/www/example.com && wp cron event run --due-now

What is actually riding on this
People treat WP-Cron as a background detail. Look at what depends on it:

That last row is the one that catches agencies out. Some form plugins offer a "background sending" option that queues notification emails through Action Scheduler instead of sending them during the request. It makes forms feel faster — and it hands your lead notifications to the very scheduler that is broken. The visitor sees "thanks, we'll be in touch". The email sits in a queue that nothing ever drains. We wrote about this failure in detail, because it is a genuinely nasty one: two independent silent failures stacked on top of each other.

Why nobody notices for months

Because a broken scheduler produces no events. That is worth sitting with for a second.

Every monitoring instinct you have is tuned to notice things that happen: an error, a 500, a slow response, an alert. A dead cron is the opposite — it is the absence of things happening. There is no error to catch, because nothing errored; there was simply nobody there to try.

Uptime monitoring is completely blind to it. The site is up. The homepage loads in 200 ms from six continents. Every check you have is green, and has been green all the way through three months of no backups.

This is the same structural blindness as a store whose orders quietly stopped: systems report events, and the disappearance of an event is not an event. Somebody has to go looking for absence — or set up something that does.

How to monitor that scheduled jobs actually ran

Two approaches, and they catch different failures. Use both.

1. Heartbeat: let the job announce itself

The most reliable check for "did it run" is to make the job say so. Schedule a task that pings a monitoring URL each time it executes; the monitor expects that ping within a window, and alerts you when it doesn't arrive.

This is the beauty of the inverted check: silence is the alarm. If the scheduler is dead, the ping stops, and you hear about it — no false positives, no guessing. It works for anything on a schedule, not just WP-Cron: nightly backups, database dumps, sync scripts. If it should have run and it didn't, you find out today, not in three months when you need the backup.

2. Inside check: is the scheduler even alive?

A heartbeat tells you a specific job stopped. It cannot tell you the scheduler is running but drowning — tasks piling up, hours overdue, on a site whose traffic isn't enough to drain the queue.

For that you need to look from inside. Our WordPress plugin reports two things: whether DISABLE_WP_CRON is set (with no server cron behind it), and how far behind the due tasks actually are. A growing backlog is the early warning that the site is quietly running on fumes — before the backup you needed turns out not to exist.

It sits alongside the other checks that only make sense from inside WordPress: modified core files, plugins with published vulnerabilities, mail going out unauthenticated through PHP-mail, autoload bloat. All invisible from the outside. All quietly expensive.

The rule this all points to

Monitor the things that should happen, not only the things that can go wrong. Error monitoring catches events. Nobody catches absences unless they deliberately decide to — and absences are where the expensive failures live: the backup that never ran, the lead email that never sent, the order that never came, the certificate nobody renewed.

WP-Cron is just the most common example. It is a scheduler that requires an audience, quietly installed on thousands of client sites that don't have one.

FAQ

Why is WordPress cron not running?

Because WP-Cron isn't a real cron: it fires when someone loads a page. Low traffic means tasks run late or not at all. If DISABLE_WP_CRON is set and no server cron replaced it, they never run — and nothing in WordPress will tell you.

What breaks when WP-Cron stops?

Everything scheduled: backups, security scans, scheduled posts, update checks, subscription renewals, follow-up emails, CRM syncs — and, on plugins that queue email in the background, the lead notifications themselves. The site keeps serving pages perfectly throughout.

How do I replace WP-Cron with a real cron?

Set DISABLE_WP_CRON to true in wp-config.php, then have the server call wp-cron.php on a schedule (system cron every few minutes, or wp cron event run --due-now). The fatal mistake is doing the first half without the second.

How do you monitor that cron actually ran?

A heartbeat check — the job pings a monitor each run, and you're alerted when the ping stops — plus an inside check that reports whether WP-Cron is disabled and how far behind the queue is.

Originally published at pingvera.com.