There is a particular kind of message no agency wants to get. It arrives late, it is from a client, and it says some version of “is the site down?”.
By the time that text lands, three bad things have already happened. The site has been down for a while. The client noticed before you did. And now you are finding out about your own infrastructure from the person paying you to look after it.
Coalface Tasks is built to close that gap, because it does something most task managers cannot: it actually watches the WordPress sites you manage, and it turns what it finds into work.
It watches the sites so you do not have to
Turn on the Site Health extension and Coalface keeps an eye on the sites you look after. It checks whether they are responding, whether the SSL certificate is valid and not about to expire, and some basic SEO signals.
Crucially, it only tells you when something changes. You get one notification when a site goes down, and one when it recovers. There is no stream of “still up, still up, still up” to tune out, so when a message does arrive, it means something. You hear about the outage from your own tools, minutes after it happens, not hours later from the client.
A problem becomes a task, on the right board
Knowing about a problem is only half the job. The other half is doing something about it, and this is where the native WordPress connection earns its place.
When Site Health flags an issue, you can turn that finding into a task with one action. Because Coalface syncs natively and two-way with WordPress, that task lands on the right board for that client, and stays in sync with their site. It is not a note in a separate monitoring tool that nobody looks at. It is a real task, in the place your team already works.
This is the thing generic task managers structurally cannot do. Bolting Trello onto a WordPress site gives you two disconnected worlds. Coalface treats the site and the work on it as one system.
And then the busywork runs itself
Now add automations, and the task starts handling its own admin.
You can set up a rule so that the moment a task is created on a client’s board, it is assigned to whoever owns that client, moved into the right column, and the assignee is notified in-app, by email, or in Slack. You did not touch it. By the time you look, the outage has already become an assigned, triaged, notified piece of work waiting for someone to act.
Here is the whole chain, with nobody awake for most of it:
- A client’s site goes down at 11pm.
- Site Health notices within minutes and records it.
- That finding becomes a task on the client’s board.
- An automation assigns it, moves it, and pings the right person.
- Your team sees a clear, owned task first thing, not a panicked client message.
Why this only works when the pieces fit together
None of these features is unique on its own. Plenty of tools monitor uptime. Plenty have automation rules. What is rare is having them in one place, wired into a task manager that talks to WordPress directly, so a monitoring alert can become a synced, assigned, notified task without you gluing three services together.
That is the point of keeping monitoring, automation and WordPress sync under one roof. The handoffs that usually leak, and the panics that usually follow, just do not happen.
The short version
- Site Health watches your clients’ sites and tells you only when something changes.
- A finding becomes a real task, on the right board, kept in sync with WordPress.
- An automation can assign, move and notify, so the task triages itself.
- You find out from your tools, not your client, and the work is already in hand.
The late-night “is the site down?” text is not inevitable. With the monitoring, the sync and the automations working together, the answer is already a task with someone’s name on it.