Watch anything your app depends on. Just ask your AI.
Payments, the nightly job, the database, the sign-up that quietly stopped. Tell your AI what matters in one sentence. It proposes the sensors, you confirm, and Guard Pro watches them around the clock.
Coming to Guard Pro- Make sure payments work, the daily email goes out every morning, and the database answers.
- propose_sensorsI suggest three sensors:
- Payments: failed payments above 3% in an hour (yours stay under 1%)
- Daily email: no ping from the 7:00 job by 7:30
- Database: answers within 300 ms
- Yes.
- get_probe_snippet · add_sensor · test_sensorDone. Each sensor starts paused and turns on when its first check passes.
- Paymentsfailed payments, hourlyPausedOK
- Daily emailping by 7:30PausedOK
- Databaseanswers within 300 msPausedOK
The costliest failures make no noise.
A site can be up, fast and green on every uptime check while the business behind it has quietly stopped. Card payments fail. The nightly sync ended three days ago. Sign-ups end at an email that never arrives. Nothing crashed, so nothing alerted.
Orders per hour, one sample day
An uptime check asks whether the page answers. A sensor asks whether the business is happening: orders, payments, sign-ups, jobs.
Many sensors alert when something that should happen did not happen in time. That is how the quiet failures get caught.
Limits come from your own history, so "unusual" means unusual for your app, not for an average one.
You say what matters. Your AI does the wiring.
Guard Pro adds tools to its MCP server, so the AI you already use (Claude, ChatGPT, Cursor and others) can set sensors up for you.
- Ask
"Watch the payments and make sure the nightly job runs." Plain words, in the chat you already use.
- Your AI proposes
A short list of sensors, each in one line, with the limits suggested from your history and what it will add to your app.
- You confirm
Nothing is added without your yes. Then your AI adds a small signed probe endpoint or a ping line to your app.
- Guard watches
A new sensor starts paused and turns on when its first check passes. From then on it is passive: you hear from it only when it matters.
123 sensors in 6 categories.
The category that fits your app comes first: a checkout means a store. Every sensor says what it catches and how it connects.
Online store
- Last order older than X hours
- Failed payments above X% in an hour
- Price on the page differs from the price at checkout
Suspicious silence
- No new order within X
- No new sign-up within X
- No backup run within X
Databases and data
- Database answers within X ms
- Last backup older than X hours
- A table suddenly emptied
Background jobs and integrations
- A scheduled job ran on time
- A job started and did not finish within X
- A key or token expires within X days
SaaS and users
- The sign-in flow works (test user)
- A paying user did not get access
- The product's core action succeeds (save, send, create)
AI features
- The AI feature answers a test question correctly
- Daily AI spend above X
- An agent looping beyond X steps
X is a limit you set. Guard suggests it from your own history.
Each sensor uses the simplest way that works.
Your AI picks the way for each sensor. You never have to choose.
Guard calls an address in your app on a schedule and checks the answer: a page, an API response, a word that must appear, a flow of a few steps.
Good for: Pages, APIs, sign-in and checkout flows, subdomains
Your job or app calls its own private ping address when something happens. A ping that does not arrive on time is the alert.
Good for: Cron jobs, backups, syncs, queues, emails the system sends
A small endpoint your AI adds to your app. Guard asks it with a signed request; it runs read-only checks inside your app and answers with a signed OK or not OK plus numbers.
Good for: Databases, internal services, keys to outside providers, business numbers
A one-click, read-only connection to a provider you already use, such as your payments, database or code host. Guard reads health and numbers; it cannot change anything.
Good for: Payments, database platforms, code hosting, AI providers
Your data stays in your app.
Sensors were designed so that watching your business never means handing over the keys to it.
Database checks run inside your app with the connection it already has. 7IT receives a signed OK or not OK and numbers.
The probe answers only requests signed with your app's own key, and signs its answer. You can replace the key in one click.
Sensors only check an app whose ownership was proven, and its subdomains. Anything else is refused.
Your AI cannot add or change a sensor without your explicit yes, and every change is recorded in the control room.
A sensor's settings never hold a key or a password. Anything that needs one is checked inside your app.
Never rows, never user data, never a response body. The probe's answer is limited in size and shape.
An enterprise-grade library. Made simple.
Enterprise teams watch hundreds of sensor types with tools like PRTG and Zabbix. Guard Pro brings a library of that depth to a founder, without the setup screens.
| Aspect | Enterprise monitoring | Guard Pro custom sensors |
|---|---|---|
| The library | Hundreds of sensor types | 123 sensors chosen for apps built with AI |
| Setting one up | Screens of settings, usually an admin's job | One sentence to your AI, then your yes |
| Database checks | Often a database login stored in the tool | Run inside your app; no password leaves it |
| Limits | You pick every number | Suggested from your own history; you approve |
| When one fires | An alert in a console | Plain words on your phone, with the likely causes and the steps |
Every sensor gets what Guard Pro already gives an app:
PRTG and Zabbix are trademarks of their owners. 7IT is not affiliated with or endorsed by them.
About custom sensors.
Can I use custom sensors today?
Not yet. Custom sensors are coming to Guard Pro, which opens soon. This page shows what is planned; the catalog may grow before it opens.
Do I need to write code?
No. You describe what to watch in one sentence. Your AI proposes the sensors, and after you confirm, it adds the small probe endpoint or the ping line to your app. You read one proposal and say yes.
Which AI tools does it work with?
Any AI assistant that can use an MCP server: Claude, ChatGPT, Cursor and others. Guard has its own MCP server for this. The same tools will also be available as a regular API with your 7IT key.
Will 7IT see my database or my users’ data?
No. Database checks run inside your own app, with the connection it already has. 7IT never receives a database password; it receives a signed OK or not OK and a few numbers. The queries stay in your code. 7IT keeps the sensor’s name, the limits you set and the results.
How are the limits set?
Many sensors have a limit, such as "no order within X hours". Guard suggests each X from your business’s own history, so you usually just approve it. You can change it any time.
Can someone point a sensor at a site that is not theirs?
No. Sensors only check an app whose ownership was proven, and its subdomains. A sensor aimed anywhere else is refused, so Guard cannot be turned against other people’s sites.
What happens when a sensor fires?
The same as the rest of Guard Pro: an alert on your phone that you control (quiet hours, mutes), the sensor’s light in the control room, and Help with the likely causes and a ready prompt for your AI. 7IT Guard watches and explains; it does not change your app on its own.
Is it part of the 7IT Guard plugin?
No. Custom sensors are paid, part of Guard Pro and Pro + personal guidance. The 7IT Guard check before you ship stays at no cost.
What will it cost?
Prices are published when Guard Pro opens. There is no waitlist form.
Watch the business, not just the page.
Custom sensors are part of Guard Pro and Pro + personal guidance. Start with the 7IT Guard check today.