DEV Community: Artem Meleshkin

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.

70 false alerts a day — why uptime monitors cry wolf — and what the fix costs

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

There is a sentence in a sysadmin thread that should end the career of any monitoring product: "anyone still on this service needs to verify, don't trust, any outage notifications." Read that again. People are paying for alerts, and then paying with their own time to check whether the alerts are real. At that point the product has inverted its own purpose. Let's look at why this happens — it is architecture, not incompetence — and at what an actual fix looks like.

What people are actually living with

These are real users, in public, about mainstream monitoring tools:

"I'm still getting over 70 false positives per day."r/selfhosted

"I've just deleted my account because they've sent me no less than 140 emails telling me things are up, down, back up again… But everything of mine is up and running."r/sysadmin

"Got paged into work because [the monitor] is claiming some of our sites are flapping… not finding a single issue."r/sysadmin

"We'd have times where the netops ring group would get 10+ false positives in a single night. They tried to blame everything on us, and then tried to blame our ISP (we are the ISP)."r/msp

And an agency describing what a WordPress plugin's built-in monitor did to them: "yesterday alone I received 69 emails, yet the site has never been down. The graph within the control panel shows the site as having 100% uptime." The tool contradicted itself in the same interface, and still sent the emails.

This is not a bug report. This is a genre.

One probe, one opinion

Most monitoring checks your site from a single location. That single probe cannot distinguish between two very different events:

Your site is down.
The path between that one probe and your site is having a bad ten seconds.

From the probe's vantage point, they are identical: a request went out, nothing came back. So it fires. Your visitors, coming from other networks, notice nothing at all.

The internet is not a wire; it is a negotiation. Routing flaps, transient packet loss, an overloaded probe host, a DNS resolver having a moment — all of it produces the same silence as a genuinely dead server. If your architecture is "one prober, one verdict", you have signed up for a permanent stream of ghosts.

The workarounds people reach for — and why they're half-fixes

"Whitelist our IPs at your firewall"

This is the most common vendor answer, and users are unimpressed:

"Their solution is to add all 100+ IPs to our firewalls allowed list. This is not feasible when you're managing SonicWALL firewalls."r/sysadmin

Sometimes the probe really is being rate-limited or blocked, and whitelisting genuinely helps. But it fixes one cause of false alerts, not the class. Routing hiccups do not care about your allowlist.

"Just raise the timeout"

Raising the timeout buys you a slower, quieter monitor — and a longer delay before you learn about a real outage. It trades one failure mode for another rather than solving anything.

Turning the monitor off

It sounds absurd until you meet an MSP that has done exactly that:

"each time we end up turning it off… as it creates false positive like crazy. We would get automated calls at night telling us servers are down etc. when there is nothing wrong."r/msp

This is the real end state of a noisy monitor. Not "we tolerate some noise" but "we disabled it". A monitor everyone has muted is worse than no monitor, because it also gives you the illusion of coverage.

The fix that works — and where it usually lives

Two mechanisms kill the overwhelming majority of false alerts, and neither is exotic:

Confirmation from multiple locations. Before declaring a site down, ask several probes in different networks and geographies. If one says "unreachable" and three say "loads fine in 200 ms", the site is fine and one probe had a bad moment. Only a quorum opens an incident.
Debouncing. Require a few consecutive failures before alerting instead of firing on the first blip. Costs you seconds on a real outage; removes an entire category of noise.

Here is the uncomfortable part. On several popular services, these fixes are premium features. A user, on the free tier, drowning:

"an easy fix would be to change settings so it only considers the service as down after 2 or 3 consecutive failed health checks, but again, this can only be done in the paid tier."r/selfhosted

Think about what that pricing decision means. The free plan is not merely limited — it is engineered to be the noisiest one, and the way out is a subscription. The product is selling you relief from a problem it kept in place.

We put both mechanisms on every plan, including the free one. Not out of generosity: an alert that people have learned to ignore is not a cheaper product, it is a broken one. If our free tier trained you to mute us, our paid tier would never get the chance.

The other side of the coin: the 5-minute blind spot

False alarms are the loud failure. There is a quiet one that costs more.

Most free tiers check every five minutes. An outage that lasts two minutes — a PHP-FPM pool exhausting itself, a database deadlock, a deploy gone wrong and rolled back — can fall entirely between two checks. You get no alert. You get a clean uptime graph. Your client gets an error page.

When a user reported exactly this, a vendor's support said the quiet part out loud: "the downtime may have been intermittent where the 5-min intervals may not have caught." That is the trade being made on your behalf: a monitor that alerts on ghosts and sleeps through the real thing.

Our checks run every minute — on every plan, free included. A one-minute interval does not eliminate the blind spot (nothing short of continuous observation does), but it shrinks it by a factor of five, and it does not require a credit card.

What good looks like

That last row is the whole point. The value of an alert is not in its delivery — it is in whether anyone believes it. Every false positive spends a little of that credit, and the balance does not refill.

One more thing a quorum gives you for free

Once several regions check independently, disagreement between them stops being noise and becomes information. If Amsterdam and Buffalo load the site fine and two other regions time out, the server is healthy and something in the network — a route, a regional block, a CDN rule — is cutting off part of the audience. A single probe cannot tell you that. It can only be right or wrong.

That is the difference between "your site is down" (often untrue) and "your site is unreachable from part of the world" (specific, actionable, and impossible to fake with one prober).

FAQ

Why does my uptime monitor say the site is down when it isn't?

Almost always because a single probe checks from a single location. A routing blip, packet loss, a DNS hiccup or the probe host being briefly overloaded looks exactly like a real outage from that vantage point. Visitors elsewhere never notice, but the monitor pages you anyway.

What actually fixes false downtime alerts?

Confirmation from multiple locations (only alert when a quorum agrees) and debouncing (require several consecutive failures). Whitelisting the monitor's IPs at your firewall fixes one cause, not the class.

Can a 5-minute check interval miss a real outage?

Yes, and vendors admit it. An intermittent two-minute outage can fall entirely between two five-minute checks — no alert, clean graph, angry client.

Is multi-location confirmation a premium feature?

On many services, yes — both confirmation and debouncing sit behind the paid tier, which makes the free plan the noisiest by design. We put both on every plan, including free, because an alert people have learned to ignore is worse than no alert.

Originally published at pingvera.com.

WooCommerce checkout monitoring — how to catch a dead checkout before the client calls

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

Here is a review that should be printed and pinned above every agency's monitor. An agency owner, writing about a WordPress management tool: "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." The site was up the whole time. Uptime monitoring had nothing to report. The client found out from his own silence.

The failure mode uptime monitoring cannot see

Uptime monitoring answers exactly one question: did the page load? That question has almost nothing to do with whether the store works.

Five ways to break a WooCommerce store while it keeps returning a cheerful 200 OK:

The payment gateway is stuck in test mode. Somebody flipped Stripe or PayPal into sandbox to debug something, verified it worked, and never flipped it back. Checkout completes. Money does not move.
An update broke the checkout page. A plugin or theme update takes out the checkout template. The homepage — the page your monitor watches — is perfectly fine.
Failed orders are spiking. Orders get created and then die at payment. Individually invisible; in aggregate, it means the gateway is broken.
The server-side order pipeline is broken. A plugin conflict means orders never get created, or hang in a limbo status. The storefront looks great.
Orders simply stopped. The most insidious one: nothing is technically "broken", the flow just went quiet. Any of the four above will do it — as will an ad campaign that died.

Notice what all five have in common: the front page is fine. This is the same class of failure as a contact form that silently stops delivering leads — the site works, the business does not.

Three cheap signals from order statistics

The naive approach is to alert when there are no orders. The naive result is an alert every night for a store that does two orders a week. So every threshold has to be normalised against that store's own baseline, never against an absolute number.

Failed-order spike

Compare the share of failed orders in the last 24 hours against the store's own seven-day norm:

failed_24h >= 3
AND (failed_24h / total_24h) > 3 × (failed_7d / total_7d)
→ critical: the gateway is probably broken
Two safety catches. An absolute floor (three failures is the minimum before statistics mean anything) and a relative one (three times the store's own rate). A store that always has some failed orders — cash on delivery, aggressive fraud rules — lives with its own baseline and never catches fire.

Order drought

Zero orders in 24 hours is a signal only if this store normally takes orders:

total_24h == 0
AND average_daily_orders_over_14_days >= 3
→ warning: this store usually sells, today it didn't
One engineering note that matters at scale: count orders with WooCommerce's paginated query and read the total, rather than pulling ID lists into memory. On a store with a hundred thousand orders, the difference between "fetch a number" and "fetch an array" is the difference between a cron job that runs and a cron job that dies on memory limits.

Gateway stuck in test mode

The only check where we had to descend into vendor specifics: WooCommerce has no universal "what mode is this gateway in" API. So walk the enabled gateways, and for a known allowlist of live providers, look at their standard sandbox settings keys.

Use an allowlist of gateway IDs, not a blind search across all plugin settings for anything named sandbox — the first unrelated plugin with a similarly named option will hand you a false critical. And the settings values themselves never leave the site: only the verdict and the gateway ID go out.

The smoke run: prove the pipeline still works

Statistics catch failures after the fact — a few orders die, then you notice. An active check is better, provided it leaves no trace in a live store.

Once a day, run a service order through the real WooCommerce API: create a hidden virtual product, create an order, add the product, calculate totals, walk it through statuses, then delete everything.

$step = 'create_product';
$product = new WC_Product_Simple();
$product->set_catalog_visibility('hidden'); // not in catalog or search
$product->set_virtual(true); // no shipping, no stock
$product->set_manage_stock(false);
$product_id = $product->save();

$step = 'create_order';
$order = wc_create_order();
$order->add_product($product, 1);
$order->calculate_totals();
$order->update_status('pending');
$order->update_status('cancelled');
// ...then delete both, whatever happens
That $step variable is not decoration. When the pipeline breaks, the valuable information is not that it broke but where: "product wouldn't save" and "totals won't calculate" send a developer to entirely different places.

And a success produces no finding at all. Absence of a signal is the health signal. Diagnostics that emit green records nobody reads are diagnostics nobody reads.

Two traps we sat on so you don't have to

WooCommerce emails are not silenced the obvious way

Your service order walks through statuses, and WooCommerce dutifully emails the store owner and the "customer". Run that daily on a live store and the owner gets a "New order" and an "Order cancelled" every single morning from a customer who does not exist.

The obvious fix is the woocommerce_email_classes filter: return an empty array, no emails. It does not work. WC_Emails::init_transactional_emails() hooks each email class onto order events back on init — by the time your cron job runs, the hooks are already attached, and swapping the class list afterwards changes nothing.

You have to hit the point WooCommerce checks immediately before sending — WC_Email::is_enabled(), which consults the woocommerce_email_enabled_{id} filter:

foreach (WC()->mailer()->get_emails() as $id => $email) {
add_filter('woocommerce_email_enabled_' . $id, 'return_false', 9999);
}
add_filter('pre_wp_mail', 'return_true', 9999); // core-level safety net
The second filter is a WordPress-core backstop: if anything other than WooCommerce tries to send during the run — a notification plugin, a CRM integration — it still will not go out. Both filters come off afterwards, so the run cannot swallow a real customer's email.

`finally` does not save you from a fatal

try/finally guarantees cleanup on an exception. A PHP fatal — memory exhaustion, an error in somebody else's plugin hooked onto woocommerce_order_status_changed — is not an exception, and finally never runs. The result: a service product and an abandoned order left sitting in a client's store. Quietly corrupting a client's data is the worst thing a diagnostic tool can do.

So on top of finally, register a shutdown function that cleans up whatever was created. And write the IDs to state immediately after each entity is created, not at the end of the step — a fatal between "created" and "recorded the ID" leaves an orphan you will never know about.

What sees what

Note the last row. We are not claiming the inside layer sees everything: it does not see what happens only in the customer's browser — a crashed cart script, a payment iframe that never loads, a stale page served from a CDN. That is what a browser-driven synthetic run is for, and it costs an order of magnitude more: a real browser on every probe, fragile per-store scripts, test orders in someone's live database.

And the inside layer has one honest blind spot of its own: if the site goes down, nobody is left inside to complain. That is what external monitoring is for. Two layers, covering each other's gaps — that is the only honest way to answer "is the store working?".

Why this matters more than uptime

An outage is loud. Everyone notices, everyone panics, someone fixes it, the client forgives you — outages happen. A broken checkout is silent. The store keeps taking visitors, the ad budget keeps burning, and the first person to notice is the owner looking at a revenue report a week later. Then the conversation is not about a plugin conflict. It is about a week of lost sales, and about why you were watching the homepage instead of the money.

FAQ

Why doesn't uptime monitoring catch a broken checkout?

Because it asks one question: did the page load? A store with a dead payment gateway, a checkout page broken by an update, or a gateway left in test mode still serves pages perfectly. Status 200, valid certificate, fast response — and not a single order goes through.

What should you actually monitor in a WooCommerce store?

Four things beyond availability: the order flow itself, the share of failed orders against the store's own baseline, whether a live gateway is sitting in test mode, and whether the checkout page still renders. Plus a periodic smoke run of the server-side order pipeline.

How do you test the pipeline without leaving traces in a live store?

Create a hidden virtual product with stock management off, create an order through the WooCommerce API, calculate totals, walk it through statuses, then delete both. Suppress all WooCommerce emails for the duration of the run, and make cleanup happen even if a step fails.

Do I need a headless browser to monitor checkout?

Not for most failures. A browser run catches front-end breakage — a crashed cart script, a payment iframe that never loads — but it is expensive and fragile. The server-side pipeline, order statistics and gateway configuration cover the majority of real failures for the cost of one PHP process. The layers complement each other.

Originally published at pingvera.com.

DEV Community: Artem Meleshkin

The monitoring agent that cannot be told what to do

The uncomfortable arithmetic of remote control

What we decided instead

What this costs — and we will not pretend otherwise

The part that is really about trust

Questions people actually ask

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

Price the risk, not the hours

What actually belongs in the plan

The table stakes (everybody has these)

The differentiators (almost nobody has these)

A structure that holds up

The month-four problem

Three pricing rules that survive contact with clients

FAQ

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

What people actually complain about

1. Sites disconnect, and the dashboard keeps showing green

2. Client reports work "randomly"

3. Support that answers in days — or never

4. Updates that break the site you were protecting

What an alternative actually has to get right

Monitoring that doesn't depend on a plugin staying alive

Alerts you can believe

Reports that always send, and always have data

The honest part: what we do not replace

If you're evaluating right now

FAQ

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

Straight from the documentation

The Elementor-specific causes, in order of frequency

1. There is no Email action

2. The From address is not your domain

3. It went to spam

4. The email arrives — and it's empty

5. A plugin or theme conflict after an update

The one thing Elementor does better than its rivals

The fix

And then, next month, it breaks again

What actually verifies delivery

FAQ

WPForms not sending email notifications — three ways leads vanish quietly

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

Failure 2: background sending, and a queue that stopped

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

The usual suspects, briefly

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

The only check that closes the loop

FAQ

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

First, what "failed" actually means

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

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

The part that makes this genuinely dangerous

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

Pattern 3: silence — the pattern everyone misreads

Reading the patterns

What monitoring this actually looks like

The uncomfortable summary

FAQ

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

The one complaint its users really do make

The deeper difference: what each tool is for

What we monitor that a maintenance platform doesn't

What we don't do — and won't

So: alternative, or addition?

FAQ

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

What the green border actually means

Where the chain actually breaks

1. No SMTP — the mail is unauthenticated

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

3. The host disabled or throttled mail()

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

5. It arrived — in the spam folder

The fix, in order

And now the real problem

What actually verifies delivery

FAQ

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

`finally` does not save you from a fatal