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.
In Guard Solo and 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.
124 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 hoursA theme update hides the pay button on phones. The site looks fine, so your ads keep running while orders quietly stop for the whole weekend. The sensor would have flagged the silence within hours, long before Monday.
- Failed payments above X% in an hourA settings change makes your card processing decline good cards, and buyers start to wonder if your store is a scam. Each tries twice, then leaves. The sensor sees the declines stack up and warns you while it is still a handful.
- Price on the page differs from the price at checkoutA sale ends on your product page but not in the cart, or the other way around. Buyers see one number and pay another, and the complaints and refunds land on you. The sensor compares both and flags the moment they disagree.
Suspicious silence
- No new order within XYour payment provider pauses your account for a document check and sends the notice to an old address. Orders stop with no error anywhere. The sensor notices the silence and alerts you before a full day of sales is gone.
- No new sign-up within XAfter a domain change your confirmation email starts landing in spam. People register, never confirm and give up, while your ads keep sending more of them into the wall. The sensor sees new sign-ups stop and tells you within hours.
- No backup run within XYour nightly backup stopped months ago when a password changed. You find out the day a bad update wipes a table and there is nothing recent to restore. The sensor expects the backup every night and speaks up the first night it misses.
Databases and data
- Database answers within X msYour database slows to a crawl under a new feature's load. Pages hang, checkouts fail and users blame your app, not the database. The sensor times a simple question to it and tells you the moment the answers start to drag.
- Last backup older than X hoursYour backups depend on a token that expired quietly. Months later a bad update corrupts your data and the newest copy you have is from spring. The sensor checks the age of the last backup and warns you the first day it is too old.
- A table suddenly emptiedA cleanup script runs against your live data instead of a test copy and empties the customers table. Every user opens an empty account. The sensor notices within minutes, while the latest backup is still fresh.
Background jobs and integrations
- A scheduled job ran on timeThe scheduled job that sends renewal reminders is switched off during a server move. Customers forget to renew and slip away without a word. The sensor expects the job on its schedule and alerts you the first time it does not run.
- A job started and did not finish within XYour nightly import starts and hangs on one bad file. It never finishes and never fails, so nothing complains. The sensor knows it started, sees it did not finish in time, and alerts you before the working day begins.
- A key or token expires within X daysA certificate or access token expires on a Saturday and the feature behind it stops. The date was known all along. The sensor counts down the days and reminds you while renewing it is still a five minute job.
SaaS and users
- The sign-in flow works (test user)A small change breaks the sign-in page for everyone who is not already signed in. Your own saved session hides it from you for days. The sensor signs in as a test user on a schedule and tells you the moment it fails.
- A paying user did not get accessA customer pays you and the upgrade never reaches their account. They paid for something they cannot use, so they ask their bank for the money back. The sensor checks that paying users have access and flags each one who does not.
- The product's core action succeeds (save, send, create)The one thing your product does, saving, sending or creating, fails after a deploy while everything else looks fine. Users try twice and leave. The sensor performs that action on a schedule and alerts you the moment it fails.
AI features
- The AI feature answers a test question correctlyYour AI feature starts giving confident nonsense after the model behind it changes. Users notice the wrong answers before you do, and trust is slow to win back. The sensor asks a known question and alerts you when the answer is off.
- Daily AI spend above XOne heavy user, or a change that doubled every prompt, sends your AI bill soaring for a week before the invoice arrives. The sensor watches the daily spend and alerts you on the first expensive day, not at the end of the month.
- An agent looping beyond X stepsAn agent gets stuck repeating one step, calling the model again and again through the night. By morning a single task has cost more than a month of normal use. The sensor sees the loop and alerts you while it is still running.
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
Fewer, better alerts.
The habits of enterprise monitoring, in plain words: several values per sensor, groups, whole business flows, suggestions from what your app already uses, one alert instead of many, and quiet planned work.
One sensor can watch several numbers at once, such as answer time and failed payments, each with a warning limit and an error limit. Yellow comes before red, so you hear early.
Put sensors in groups such as Checkout or Nightly jobs, and tag them. A setting on a group, such as where alerts go, applies to every sensor in it. Edit many at once, or clone one.
One light for a whole flow: sign-up, payment and the welcome email together. It turns red when the flow breaks, and says which step failed.
Guard looks at what your app already uses, from the outside and from the checks it already runs, and suggests sensors that fit. Nothing is added until you say yes.
When the database is down, everything that needs it fails too. You get one alert about the database, not ten about everything behind it.
Planned work, once or on a schedule. Sensors keep checking and recording but stay quiet, and the history shows the window.
The principles behind each one: How sensors behave, in the catalog.
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 | 124 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 |
| When many fail at once | Dependencies you map by hand in a setup screen | One alert about the cause |
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?
Yes, with Guard Solo (up to 5 on the site) and Guard Pro (up to 10 per site).
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 Solo, 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 Solo, Guard Pro and Pro + personal guidance. Start with the 7IT Guard check today.