These are features people ask for in job and backup monitoring, each classified with the same honesty as the original idea. Being in demand doesn't mean you should build it. Most of these demands are already met by someone.
Legend: TS = Table stakes, D = Differentiator, X = Distraction, L = Liability. Priority: P0 = v1 of the recommended wedge, P1 = next, P2 = later, — = don't build.
Demand signals are drawn from competitor feature lists and pricing pages (see research/10). No survey of MSPs was run. Treat demand levels as judgment until your first 15 calls confirm them.
| Feature | Demand signal | Category | Priority | Notes |
|---|
Per-client inbound email address (e.g. acme@in.yourtool.com) | High for MSPs. Backup tools email reports by default. | D | P0 | The core of the wedge. Use two inbound providers for redundancy. |
| Templates for the top 8 backup products (Veeam B&R, Veeam Agent, Acronis, Synology Hyper Backup, Windows Server Backup, MSP360, Comet, Datto) | High | D | P0 | Which 8 is unverified. Let the concierge phase decide. |
| "Teach it" rules (mark the words that mean success, warning, failure; set expected size range) | High | D | P0 | Covers the long tail without code. Healthchecks has keyword filters, but not per-client or per-product. |
| HTTP ping URL with start, success and fail signals | High | TS | P0 | For scripts and database dumps. |
| Measure run time (start and end pings) | Medium | TS | P1 | Flags a backup that "succeeded" in 4 seconds. |
| Backup size and file-count sanity checks (from the report) | Medium-high | D | P1 | "Succeeded, but 0 bytes" is a classic silent failure. |
| Native backup-vendor APIs | Medium | TS at scale | P2 | Only when 5+ paying MSPs need the same one. |
| Kubernetes CronJob agent | Medium (developers) | X | — | Cronitor has one. Wrong buyer. |
| Laravel / Rails / Django packages | Medium (developers) | X | — | Laravel has first-party tools. |
| Cloud storage check (did a new object land in the S3 bucket?) | Medium | D | P2 | Useful for DIY database backups. Needs read-only credentials, so handle carefully. |
4.2 Alerting and noise control
| Feature | Category | Priority | Notes |
|---|
| Email, Teams and Slack alerts | TS | P0 | Teams may matter more than Slack for MSPs (assumption). |
| Email-to-ticket into the MSP's PSA | D | P0 | Works with any PSA that accepts email tickets. Zero integration maintenance. |
| Daily digest ("112 jobs: 108 OK, 3 failed, 1 missing") | D | P0 | Makes silence visible. Replaces the morning email-reading routine. |
| Alert grouping and quiet hours | TS | P1 | Backup Radar markets "cut non-urgent alert noise by up to 90%". Noise is the churn driver. |
| Maintenance windows and snoozes | TS | P1 | Stops false alarms when a client's server is down on purpose. |
| Native PSA APIs (HaloPSA, ConnectWise, Autotask, Syncro) | TS at scale | P2 | Adds ticket status sync. Only after email-to-ticket proves the need. |
| SMS and phone calls | L / TS | P2 | Fraud risk (Healthchecks lost ~$1,800 to SMS pumping in May 2026). Cap, meter and allow-list countries. |
| PagerDuty / Opsgenie | TS (developers) | P2 | Rare for small MSPs. |
| Webhooks | TS | P1 | Cheap, and lets technical MSPs automate. |
4.3 Proof and reporting (the reason to renew)
| Feature | Category | Priority | Notes |
|---|
| Monthly white-label client report (PDF) | D | P0 | The MSP sends it to its client. It's how the MSP justifies its backup fee. |
| Restore-test log with quarterly reminders | D | P1 | Who tested what, when, and the result, with an optional screenshot. Insurers ask about restore-test frequency (medium confidence). |
| Insurance evidence export (backup success rate, last restore test, off-site copy noted) | D | P1 | Say "evidence", never "compliant". |
| Client-facing read-only link | D / L | P2 | Useful, but a login for every client is support load. PDF first. |
| SLA and RPO tracking per client | TS | P2 | Backup Radar has it. Needed to win MSPs with 50+ clients. |
| QBR slide or summary for the MSP's quarterly client review | D | P2 | Cheap to generate from the same data. |
4.4 Workspace and account
| Feature | Category | Priority | Notes |
|---|
| Clients as the top-level object | D | P0 | The developer tools organise by project, not by client. |
| Unlimited technicians per MSP | TS | P0 | Healthchecks made team size unlimited in Feb 2026. Don't charge per seat. |
| SSO (Microsoft Entra ID) | TS | P2 | MSPs live in Microsoft 365. Add once there are MSPs with 10+ techs. |
| Two-factor login | TS | P0 | You hold a map of every client's backup setup. |
| Audit log of who changed a rule | TS | P1 | Protects you when an MSP asks "why wasn't I alerted?" |
| Data region choice (EU or US) | TS | P1 | UK and EU MSPs will ask. |
4.5 Things people ask for that you should not build
| Feature | Category | Why not |
|---|
| Uptime and website checks | X | UptimeRobot, Better Stack, Oh Dear, Hyperping. The most crowded idea in the catalog (C2). |
| Status pages | X | Same. |
| Running the backups yourself | L | You'd become a backup vendor, with its liability. |
| Automated restore testing inside client networks | L (for now) | Needs an agent with admin access at every client. A security and support burden. Log tests; don't run them. |
| Log search or APM | X | A different, funded category. |
| AI "backup health score" as the headline | X | Nice copy, no reason to buy. A clear red/green board beats it. |
| On-premise version | X | Doubles operations. |
4.6 Net effect
Of roughly 40 features, about 12 are real differentiators for the MSP wedge, and about 10 belong in v1. The developer-oriented features (Kubernetes, Laravel, PagerDuty, uptime) are table stakes in someone else's market.