You are responsible for sites you don't own.
On hosting you did not choose, running plugins somebody else installed, for clients who will call you — not their host — when it goes down. And from next year, for clients who will ask whether their site is DPDP compliant, and expect you to know.
The check is free, needs no account, and gives you something specific to take to that client whether or not you ever speak to us.
Three things that change when the sites aren't yours.
The report has to have your name on it
A monthly PDF that says Servertorch across the top tells your client you resell somebody else's tool. The same report with your logo and your colours tells them you run monitoring. Same data, entirely different conversation at renewal.
With white label, reports carry your logo and colour — set once.
One client must never see another
Not as a setting you remember to check. Every query in the console is scoped to a company, every agent token belongs to one site, and a report generated for one client cannot contain a row from another. It is the part of the schema with tests written specifically to try to break it.
Separate companies, separate logins, separate data — enforced in the queries, not the UI.
Compliance is about to be billable
India's DPDP obligations apply from 13 May 2027, with penalties up to ₹250 crore. Your clients are going to ask. A readiness report per site, rechecked weekly, with findings and the exact fix for each one, is a retainer line item — and it is one you can deliver in an afternoon rather than subcontract.
A per-site readiness report you can put a price on.
One console for every client.
Each client is its own company in Servertorch, with its own sites, people, alert routes and retention. You switch between them; they never see each other.
- Viewer logins for clients. A client can see their own uptime and reports without being able to change anything.
- Alerts where your team already is. Slack, Teams, Telegram or a webhook per site, so client A's outage lands in client A's channel.
- Code audit on the repositories you deploy. Verified against the live site before findings show, so nobody scans code that is not theirs.
- Works on whatever your clients run. One PHP file on shared cPanel, a package for Node.js, Python, .NET, Java, Go or Ruby, or an edge guard for static sites.
The DPDP conversation, as a service.
You already know most of your clients' sites load analytics before anything resembling consent, name no grievance officer, and have a privacy policy somebody pasted in 2019. None of them know it.
The readiness check shows them, per site, in fifteen seconds — specific enough to argue with, and everything it reports is something you can fix and then prove you fixed.
What it never does is tell anybody they are compliant. That is a legal opinion, and a liability you do not want. Findings and fixes; the verdict stays with their lawyer.
- Run the free check on every client domain
No account needed. You will have a list of specific problems across your whole book by the end of an afternoon.
- Take the worst three to the client
Not a compliance lecture. "Your analytics is setting a cookie before anyone consents, your policy names nobody to complain to, and here is the deadline." Those are three sentences and a date.
- Scope the remediation
Most of it is small: a consent gate that actually gates, a named officer, a retention line, a header. The value is knowing which ones and in what order.
- Put it under monitoring
The site goes into Servertorch, gets rechecked weekly, and you get an email when something changes — usually because their marketing team added a tag on a Tuesday. That email is the reason the retainer renews.
The questions that come up on every call.
Half my clients are on shared cPanel hosting with no SSH.
That is the case the agent was written for. It is one PHP file you upload to the web root — PHP 7.2 and up, no extensions, no root, no cron required on their side. It works on the hosting your clients actually have rather than the hosting a monitoring vendor wishes they had.
I am not putting a mystery file on a client's server.
Reasonable. It is a single readable file, it is yours to inspect before it goes anywhere, and everything it collects is visible to you in the console. The agentless tier needs nothing installed at all, so you can start there and add the agent to the sites where it earns its place.
What happens when I lose a client?
You remove the site and the agent stops reporting. Their data goes with your retention setting. Nothing about the arrangement makes it awkward to hand a site over — an agency tool that holds your clients hostage is a tool you will resent.
Who gets the alerts — me or the client?
Whichever you set up. Most agencies keep alerts to themselves and give the client a monthly report, because a client who gets a 3 a.m. certificate warning phones you about it anyway. Both is also fine: severity routing means they can get the outages and you get everything.
I bill my clients. Can I invoice through this?
Servertorch invoices you, with GST worked out properly — CGST and SGST within your state, IGST across it, zero-rated if you are exporting under an LUT — and a printable copy your accountant can file. Billing your own clients stays in whatever you already use.
The plans agencies pick.
Your brand on the console and every client report, enough sites for the whole book, and assisted support when a client asks a hard question.
Pick your worst client site.
Run the free check on it. If what comes back is not worth a conversation with that client, nothing here will be worth your time either — and you will have lost fifteen seconds.