/tools · 7IT Guard Pro · Custom sensors · Catalog
The custom sensor catalog
Every sensor in Guard Solo and Guard Pro: what could happen without it, what it catches, how it connects to your app, and where you set the limit. Below the tables: the probe endpoint, the ping address, the MCP tools and how sensors behave, at the level of principles.
In Guard Solo and Guard Pro124sensors
6categories
4ways to connect
The catalog
Filter by category or by how it connects.
X A limit you set. Guard suggests it from your business's own history; you approve or change it.
Pull Guard checks your app Ping Your app pings Guard Probe Signed probe in your app Provider Read-only provider connection
Part of the Guard Pro watch Already among the checks Guard Pro runs on every watched app.
No sensor matches. Try another word or set a filter back to All.
Online store
22 sensorsThe checks a store owner wishes they had the week the checkout broke quietly.
| Sensor | What it catches | How it connects | Your limit |
|---|---|---|---|
| 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. | The checkout broke quietly | Probe | X you set |
| Checkout page loads and shows the pay buttonA plugin update leaves your checkout as a blank white page. Shoppers fill their carts, press pay, see nothing and buy from a competitor. The sensor checks that the pay button is there and alerts you in minutes. | A broken checkout | Pull | No limit to set |
| Add to cart works (a flow of a few steps)After a deploy, the add to cart button spins and does nothing. Every visitor you paid to bring in leaves with an empty cart. The sensor walks through the steps like a shopper and tells you the moment one fails. | A cart that does not update | Pull | No limit to set |
| 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. | A problem with card processing | Providere.g. Stripe | X you set |
| Payment webhook not deliveredCustomers pay and the money arrives, but your app never hears about it. Orders sit as unpaid, nothing ships, and the where is my package emails begin. The sensor notices the missing payment notices before the first complaint. | Orders that are never marked as paid | Providere.g. Stripe | No limit to set |
| Payments and orders differ by more than XMoney comes in for orders your system never recorded. Weeks later a customer who paid and got nothing tells you, and you have to hunt for all the others. The sensor compares the two and points at the gap while it is small. | Lost orders | Probe | X you set |
| Best seller out of stock or below X unitsYour best seller sells out on a Friday night while the page still says in stock. Buyers get cancellation emails and remember it. The sensor warns you while there are still units left and time to restock. | Sales that stop | Probe | X you set |
| A product price changed by more than X%A bulk edit drops a decimal point and your best product now sells for a tenth of its value. Bargain hunters find it before you do. The sensor flags the jump as it lands, so you fix one listing instead of a hundred orders. | A mistake or a break-in | Probe | X you set |
| A coupon used abnormally (over X uses an hour)A discount code meant for one loyal customer ends up on a coupon forum. By morning it has been used hundreds of times on your thinnest margins. The sensor catches the unusual run of redemptions within the hour. | A coupon code that leaked | Probe | X you set |
| Order confirmation email sentYour email sender stops after a password change. Customers pay and hear nothing, so some assume fraud and call their bank. The sensor expects a confirmation for every order and tells you as soon as they stop going out. | Customers who get no confirmation | Ping | No limit to set |
| Shipping cost is calculatedThe shipping rates service you rely on changes its answer, and checkout charges nothing for delivery. You pay the shipping on every order until the carrier bill arrives. The sensor checks the quote and alerts you the hour it breaks. | A shipping calculator that went down | Pull | No limit to set |
| Store search returns resultsYour search index is wiped in a hosting move, and every search comes back empty. Shoppers who know exactly what they want decide you do not sell it. The sensor runs a search that should find something and tells you when it does not. | Broken search | Pull | No limit to set |
| Product images loadYou switch storage and every product photo turns into a broken icon. Nobody buys what they cannot see, and the store looks abandoned. The sensor loads a product image on a schedule and alerts you before a shopper sees the gap. | Broken images after a storage change | Pull | No limit to set |
| Inventory sync ran in the last X hoursThe sync with your warehouse dies after a login change, and the store keeps selling items that ran out days ago. Then come the cancellations and refunds. The sensor expects the sync on schedule and speaks up the first time it misses. | Stock levels out of date | Ping | X you set |
| Orders not shipped within X daysAn order gets stuck in a status nobody looks at. The customer waits a week, opens a payment dispute and leaves a one star review. The sensor watches for orders that sit unshipped too long and puts them in front of you first. | Fulfillment running late | Probe | X you set |
| Refunds or cancellations above X%A bad batch reaches customers, or someone is testing stolen cards on your store. Refunds pile up and your payment provider starts asking questions. The sensor sees the rate climb while it is still a pattern, not a crisis. | A product problem or fraud | Probecomputed inside your app | X you set |
| New payment disputesPayment disputes arrive at an inbox nobody reads. The deadline to answer passes, you lose each one by default, and your payment account is put under review. The sensor tells you about every new dispute while there is time to respond. | Risk to your payment account | Pingfrom your payment webhook | No limit to set |
| 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. | A pricing fault | Pull | No limit to set |
| Product page slower than X secondsA new tracking script makes your product pages crawl on phones. Shoppers tap, wait, and go back to the search results while your ad budget keeps paying for the click. The sensor times the page and warns you when it slows. | Shoppers who leave | Pull | X you set |
| Daily order value X% below normalSales slide all week and you blame the season. In fact a checkout bug on one phone model has been turning buyers away since Tuesday. The sensor compares each day with your normal and raises it on the first bad day. | A drop in sales | Probe | X you set |
| Abandoned carts above X%A new step asks for an account before payment, and buyers walk away at the last screen. You would see it in the monthly numbers, a month too late. The sensor sees abandonment rise and tells you within days. | A checkout that drives buyers away | Probe | X you set |
| Contact form submitsYour contact form has failed silently since the redesign. A buyer with a large order wrote twice, heard nothing, and went elsewhere. The sensor sends a test message on a schedule and tells you when the form stops accepting it. | Messages that never arrive | Pull | No limit to set |
Suspicious silence
21 sensorsThe strongest category for a founder. Most expensive failures do not look like an error; they look like nothing happening. Each sensor alerts when something that should happen did not happen within X hours or days.
| Sensor | What it catches | How it connects | Your limit |
|---|---|---|---|
| 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. | A broken checkout or payment | Probe | X you set |
| 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. | A broken sign-up, or a verification email that never arrives | Probe | X you set |
| No successful sign-in within XA security update breaks sign-in for anyone with a saved password. Paying customers are locked out of what they pay for, and the first sign is a cancellation. The sensor sees that nobody has signed in and wakes you. | Broken sign-in | Probe | X you set |
| No successful payment within XYour payment keys are replaced and the live site keeps using the old ones. Every checkout fails politely and the dashboard just shows a slow day. The sensor knows how often you get paid and alerts you when the payments stop. | Card processing that got stuck | ProviderProbe | X you set |
| No subscription renewal within XA change to your subscription setup means renewals stop charging. Customers keep using the product, you keep paying for servers, and a month of revenue drains away. The sensor flags the first day renewals do not come in. | Recurring charges that fail | Providere.g. Stripe | X you set |
| No email sent by the system within XYour email provider suspends the account after one spam complaint. Password resets, receipts and welcome emails all stop, and nothing tells you. The sensor expects your app to send mail and alerts you when it goes quiet. | The email provider blocked or suspended the account | Ping | X you set |
| No SMS or WhatsApp message within XYour text message account runs out of credit overnight. Sign-in codes and appointment reminders fail, customers miss bookings and support fills with people who never got a code. The sensor notices the silence at once. | The messaging provider stopped | Ping | X you set |
| No contact form lead within XA form update breaks the submit button on your quote page. For a week, every potential client who asks for a quote disappears without a trace. The sensor expects leads at your usual pace and tells you when they stop. | A broken form | Probe | X you set |
| No user file upload within XYour file storage fills up and every upload fails with a vague message. Users decide your app is broken and leave without a word. The sensor sees that nobody has uploaded anything and alerts you before the reviews do. | File storage full or blocked | Probe | X you set |
| 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. | Backups that stopped | Ping | X you set |
| No sync from an outside system within XThe partner service you sync with changes its access rules and your data stops updating. Your customers act on numbers that are days old and trust you less each time. The sensor expects each sync and alerts you when one is missing. | An expired key or an API that changed | Ping | X you set |
| No hourly or daily scheduled job within XA hosting change switches off your scheduled jobs. Invoices are not sent, trials never end and reminders never go out, all without one error. The sensor expects every job to report in and tells you when one goes quiet. | A scheduler that was switched off | Ping | X you set |
| No content update (post, product, page) within XYour content system gets stuck after an update and nothing you publish actually appears. You announce a launch and send people to an old page. The sensor notices that nothing new has gone live and tells you in time. | A content system that is stuck | Probe | X you set |
| No call to the app's AI feature within XThe AI feature at the heart of your product fails for every user after a provider change, but the page looks normal. Users try once, shrug and do not return. The sensor notices nobody is using it and alerts you the same day. | The AI feature failing quietly | Probe | X you set |
| No analytics event from the site within XA deploy removes your tracking code. Reports show a quiet month, you cut the campaign that was working, and decisions are made on data that is not there. The sensor expects events from the site and tells you when they stop. | Tracking code removed in a deploy | Ping | X you set |
| No home page visit within XA settings change points your domain to the wrong place, but your own browser still shows the old page from memory. Real visitors see an error page. The sensor expects real traffic and alerts you when it vanishes. | The site not reachable for real users | Ping | X you set |
| No job completed in the queue within XYour queue looks busy, but nothing comes out the other end. Reports, emails and imports wait in line, and your customers wait with them. The sensor expects finished work and tells you when the line stops moving. | A stuck queue | Probe | X you set |
| No invoice issued within XA tax setting change breaks your invoicing step. Work is delivered, nothing is billed, and you only notice when the bank balance looks thin. The sensor expects invoices at your usual pace and alerts you when they stop. | An invoicing system that is stuck | Ping | X you set |
| No daily report sent to the admin within XThe morning summary you rely on stops arriving, and you assume it was a quiet day. Meanwhile the problem it would have shown you keeps growing. The sensor expects the report each day and tells you when it does not come. | Reports that stopped | Ping | X you set |
| No new deploy within X (for projects that ship daily)You ship every day, but the pipeline has failed since Tuesday and nobody looked. The fix your biggest customer is waiting for never went out. The sensor expects new deploys and tells you when they stop arriving. | A deploy pipeline that is stuck | Pulldeploy fingerprint | X you set |
| Not even one active user within XYour app works perfectly for nobody. A broken link in the welcome email means new users never get in, and the dashboard is just quiet. The sensor alerts you when not a single person has used the app. | An app that is empty in practice | Probe | X you set |
Databases and data
20 sensorsChecked from inside your app, with the connection it already has. 7IT never receives a database password.
| Sensor | What it catches | How it connects | Your limit |
|---|---|---|---|
| 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. | An outage or slowness | Probe | X you set |
| Open connections above X% of the limitA traffic spike, or a bug that never lets go of connections, fills every slot your database allows. The next visitor gets an error instead of your app. The sensor sees the slots filling and warns you before they run out. | "Too many connections" on the way | Probe | X you set |
| Database size above X% of the planYour database reaches the size limit of its plan and turns read-only. Nobody can sign up, buy or save anything until you notice and upgrade. The sensor watches the growth and tells you while there is still room. | A switch to read-only mode | ProbeProvider | X you set |
| A table growing abnormally fastA bug writes the same row over and over, or bots flood your sign-up table. Your storage bill climbs and every page slows. The sensor notices a table growing far faster than it normally does and alerts you within the hour. | A bug that duplicates rows, or spam | Probe | No limit to set |
| 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. | Accidental deletion or a break-in | Probe | No limit to set |
| A known query slower than XA tidy-up removes an index nobody remembered mattered. The page that lists orders now loads so slowly that customers give up on it. The sensor times that query and tells you the day it gets slow, not the month. | An index that is missing or was dropped | Probe | X you set |
| 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. | Backups that stopped | PingProvider | X you set |
| The last tested restore passedYou back up every night, and none of the copies can be restored because a setting changed. You learn it on the worst possible day. The sensor checks that the last test restore really worked, so the day you need it, it does. | A backup you cannot restore from | Ping | No limit to set |
| Orphan records (an order with no customer) above XA deploy breaks the link between orders and customers. Orders keep coming in, but nobody can tell who placed them or where to ship. The sensor counts broken records and alerts you while there are a few, not thousands. | Data that broke | Probe | X you set |
| A public table without row level securityA new table goes live with its access rules off while your app's visitor and signed-in roles still hold a grant on it. Anyone who knows where to look sees your users' details. The sensor spots the open table before a stranger does. | Data visitors can read or change, when the public roles have a grant on the table | Probechecked inside your app | No limit to set |
| A risky database setting appearsA change leaves a table open or a function unsafe, and nobody sees the warning. It stays open for weeks. The sensor checks these settings from inside your app and tells you the day a new one appears. | Open tables, missing access rules, unsafe functions | Probechecked inside your app | No limit to set |
| The project is close to pausing for inactivity Part of the Guard Pro watchYour database provider pauses projects that look idle, and yours had a quiet week. On Monday morning your app cannot reach its data at all. The sensor sees the pause coming and warns you while one click still prevents it. | A database that falls asleep | PullProvider | No limit to set |
| Query errors above X an hourA deploy renames a column but misses one place in the code. Every checkout that touches it fails with an error users never report. The sensor counts database errors and alerts you within the hour of the deploy. | Code that broke against the database | Ping | X you set |
| Locks waiting more than X secondsA long report locks the orders table in your busiest hour. Every checkout waits, then fails, and nobody knows why. The sensor sees queries stuck behind the lock and tells you while you can still stop the cause. | A lock that freezes the app | Probe | X you set |
| The cache (Redis) answersYour cache goes down and every request falls through to the database at once. The app slows, then stops answering. The sensor checks that the cache answers and alerts you before the database gives out too. | Cache down | Probe | No limit to set |
| Cache memory above X%Your cache fills up and starts throwing away what it holds, sign-ins included. Users are logged out mid-task and carts empty themselves. The sensor watches the memory and warns you before it overflows. | Data pushed out of the cache | Probe | X you set |
| File storage above X% of the planYour storage plan is nearly full, and the next customer upload fails with a message nobody understands. They try again, then leave. The sensor watches how full it is and tells you while there is room to grow. | Uploads that are about to fail | Probe | X you set |
| A storage bucket turned publicA storage setting flips to public during a late debugging session and stays that way. Invoices, ID scans and private photos are one link away from anyone. The sensor tries a private file you name and alerts you the same hour it opens. | Users' files leaking | Pulla file you name | No limit to set |
| A migration that did not completeA database update stops halfway through a deploy. Part of your app expects the new layout and part the old, and the errors look random. The sensor notices the unfinished update and points you straight at it. | A deploy stuck halfway | Probe | No limit to set |
| Replica lag above X secondsYour read copy of the database falls behind. Customers pay, the screen still says unpaid, and some pay a second time. The sensor measures the delay and tells you when users start seeing stale data. | Users shown stale data | Probe | X you set |
Background jobs and integrations
21 sensorsThe work nobody sees until it stops: scheduled jobs, queues, webhooks and the outside services your app calls.
| Sensor | What it catches | How it connects | Your limit |
|---|---|---|---|
| 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 cron job that was switched off | Ping | No limit to set |
| 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 stuck job | Pingstart and success pings | X you set |
| A job failed (exit code)Your payout job fails every night with an error that lands in a log nobody reads. Partners go unpaid and start asking questions. The sensor hears the failure and tells you the same night. | An error during the run | Pingfail ping | No limit to set |
| A job took longer than XYour nightly job takes a little longer every week as your data grows. One day it runs into business hours and slows the whole app. The sensor sees the run time creeping up and warns you while it is still a planning problem. | Load that keeps growing | Ping | X you set |
| Queue above X jobsA sale brings more work than your workers can handle, and the queue grows faster than it drains. Order confirmations arrive hours late. The sensor sees the backlog build and alerts you while adding a worker still helps. | Workers that cannot keep up | Probe | X you set |
| The oldest job has waited more than XOne job at the front of your queue keeps failing and retrying, and everything behind it waits. Customers wait for exports that never come. The sensor sees how long the oldest job has been waiting and raises it with you. | A stuck queue | Probe | X you set |
| Jobs that failed for good (dead letter)Jobs that failed for good land in a pile nobody checks. Some of them were refunds, some were welcome emails. The sensor counts the lost work and tells you before customers notice what never happened. | Work that was lost | Probe | No limit to set |
| Incoming webhooks failed above XA provider changes how it signs its messages and your app starts rejecting every one. Payments, shipping updates and sign-ups stop arriving. The sensor counts the failed deliveries and alerts you within the hour. | A provider that stopped sending | Ping | X you set |
| An outside API key worksA key to an outside service is revoked after a security review on their side. The feature that depends on it breaks for every user at once. The sensor tries the key on a schedule and tells you the moment it stops working. | A key that expired or was revoked | Probe | No limit to set |
| 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. | A failure you can see coming | Probe | X you set |
| The email provider accepts requestsYour email provider starts refusing your requests after a plan change. Receipts, resets and invites stop, and users think you are ignoring them. The sensor checks that the provider still accepts your mail and alerts you right away. | Emails that are not going out | Probe | No limit to set |
| Bounced emails above X%An import of old addresses sends your bounces up, and inbox providers start treating all your mail as spam. Soon even password resets go missing. The sensor sees the bounces rise and warns you before your sending reputation sinks. | Getting blocked on the way to inboxes | Probe | X you set |
| The SMS provider answersYour text message provider has an outage and sign-in codes stop arriving. Users cannot get into their accounts and you cannot tell why. The sensor checks that the provider answers and tells you before the support queue fills. | Messages that are not sent | Probe | No limit to set |
| An outside rate limit was exceededAfter a change your app calls a partner service too often, and it blocks you for the rest of the day. Maps, rates or lookups break for every user. The sensor counts the refusals and tells you at the first one. | A temporary block that breaks a feature | Ping | No limit to set |
| Function volume spike (runs or outside calls above normal)A bug sends a function into a loop, or a stranger finds an open endpoint and hammers it all night. By morning your project is suspended or the month's budget is gone. The sensor knows your normal pace and alerts you as the jump starts. | A runaway loop, or a stranger hammering an open endpoint | Pingcounts per function and outside service | No limit to set |
| The CRM or spreadsheet sync ranThe sync from your forms to your sales sheet stops after a password change. New leads pile up somewhere nobody looks and go cold. The sensor expects the sync and tells you the first time it does not run. | Leads that never arrive | Ping | No limit to set |
| A customer export or report was producedThe weekly report your biggest client relies on fails to generate. They notice before you do, and start wondering what else is broken. The sensor expects the export and tells you the moment it is missing. | A process that failed | Ping | No limit to set |
| Image or video processing finishedVideo uploads get stuck in processing after a library update. Your creators publish, their audience sees a spinner, and both blame you. The sensor expects processing to finish and alerts you when it does not. | A heavy process that is stuck | Ping | No limit to set |
| Jobs that ran twice (duplicates)A retry setting makes your billing job run twice. Every customer is charged twice, and by morning your inbox and your dispute count are full. The sensor sees the duplicate run and alerts you while it is still a few. | Double emails or double charges | Ping | No limit to set |
| The background worker is connected and aliveYour background worker crashes and does not restart. The site still loads, but nothing behind it happens: no emails, no exports, no processing. The sensor expects the worker to report in and tells you when it goes quiet. | A worker that crashed | Ping | No limit to set |
| GitHub Actions run succeeded Part of the Guard Pro watchYour deploy workflow has failed for days and the fix you promised a customer never went live. They check, still see the bug, and lose patience. The sensor reads every run and tells you after the first failure. | A deploy or tests that failed | ProviderGitHub | No limit to set |
SaaS and users
20 sensorsSign-in, subscriptions and the one action your product exists for, watched the way a user meets them.
| Sensor | What it catches | How it connects | Your limit |
|---|---|---|---|
| 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. | Sign-in broken after a change | Pulla flow of a few steps | No limit to set |
| Failed sign-ins above X% an hourA change to how passwords are checked rejects correct ones. Customers think they forgot theirs, reset it and fail again. The sensor sees failed sign-ins jump and alerts you within the hour, whether it is a bug or an attack. | A sign-in fault, or break-in attempts | Probe | X you set |
| A burst of sign-in attempts from one sourceSomeone runs a list of leaked passwords against your sign-in page overnight. A few customer accounts open, and you hear about it from those customers. The sensor sees the burst from one source and alerts you while it is happening. | Password guessing | Probe | No limit to set |
| Suspicious sign-ups above X an hourBots find your sign-up form and create thousands of fake accounts, each one sending a welcome email. Your mail starts landing in spam for real users. The sensor sees the flood and tells you in the first hour. | Bots and spam | Probe | X you set |
| The verification email goes out within X minutesYour verification email starts taking hours to go out. New users wait, give up and sign up with a competitor instead. The sensor times each one from sign-up until your email provider takes it and tells you when it gets slow. | Users stuck at sign-up | Probesent, not opened: no inbox is read | X you set |
| The password reset request worksPassword reset stops working after a change to your sign-in setup. Every user who forgot a password is locked out, and many leave. The sensor asks for a reset for a test account, opens the reset page and tells you the day it breaks. | Users locked out | Pull | No limit to set |
| Sign-in with Google or GitHub worksSign-in with an outside account breaks after the provider changes a rule, and most of your users only ever sign in that way. To them, your app is simply gone. The sensor tries it on a schedule and tells you within minutes. | A sign-in provider that broke | Pull | No limit to set |
| Active subscriptions dropped X% in a dayA card update screen fails and subscriptions start lapsing in a single day. By the time the monthly report shows it, those customers are gone. The sensor sees the drop the same day, while you can still reach them. | Cancellations or failed charges | Probecomputed inside your app | X you set |
| Failed recurring charges above XRecurring charges begin failing after a change to your payment setup, and nobody is asked to update their card. Revenue leaks out month after month. The sensor counts the failed charges and alerts you at the first wave. | Revenue being lost | Pingfrom your payment webhook | X you set |
| 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. | Permissions that do not update | Probe | No limit to set |
| A cancelled user still has accessCustomers who cancel keep full access because a status update never runs. You keep serving them, and paying for it, for months. The sensor checks that cancelled users lose access and tells you when they do not. | Service given away after cancelling | Probe | No limit to set |
| Daily active users X% below normalA bug on one phone model signs users out every time they open the app. They do not complain; they just stop coming. The sensor compares today with your normal and tells you on the first day of the drop. | A bug that drives users away | Probe | X you set |
| 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. | The main feature broke | PullProbe | No limit to set |
| Inviting a user to a team worksInviting a teammate breaks, and every new account stays a team of one. Growth stalls and you blame the market. The sensor sends a test invite on a schedule and tells you when it stops working. | Growth that is blocked | Pull | No limit to set |
| A user's data export completesA user asks for a copy of their data, as privacy law allows, and the export quietly fails. Weeks later a regulator asks why they never got it. The sensor checks that exports complete and tells you when one does not. | Privacy requests left unhandled | Ping | No limit to set |
| Account deletion requests waiting more than X daysRequests to delete accounts sit in a queue nobody processes. The legal deadline passes and a complaint reaches the privacy regulator. The sensor tells you when a request has waited too long, while you are still within time. | Legal exposure | Probe | X you set |
| Users go past their plan's limitsUsers on your entry plan use far more than it allows because a limit check stopped working. Your costs grow and the reason to upgrade disappears. The sensor sees users past their limits and tells you who they are. | Limits that are not enforced | Probe | No limit to set |
| User notifications (push, email) were sentPush and email notifications stop after a provider change. Users miss the reminders and updates that bring them back, and slowly drift away. The sensor expects notifications to go out and tells you when they stop. | A notification system that is stuck | Ping | No limit to set |
| Main API response time above XYour app's main data starts answering slowly after a change, and every screen feels heavy. Users cannot say why; they just use it less. The sensor times the answer and warns you when it slows. | Slowness users can feel | Pull | X you set |
| A burst of errors on users' screens above X a minuteA browser update breaks a script on your page and users see a frozen screen. They never report it; they leave. The sensor counts errors on users' screens and alerts you within minutes of the first wave. | Crashes on the user's side | Pingfail ping | X you set |
AI features
20 sensorsMost apps built with AI also use AI. Here the risk is both money and quality.
| Sensor | What it catches | How it connects | Your limit |
|---|---|---|---|
| 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. | A broken feature | Probe | No limit to set |
| 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. | A bill that blows up | Probe | X you set |
| One user consumes more than X% of the spendOne account discovers your AI feature and runs it as a personal service, at your cost. Everyone else gets slower answers. The sensor sees one user taking a large share of the spend and tells you who it is. | Abuse | Probe | X you set |
| AI provider rate-limit errors above XA launch brings more traffic than your AI provider allows on your plan. Users see errors, decide the feature is broken and leave on launch day. The sensor counts the rate-limit errors and tells you within minutes. | Hitting the provider's rate limit | Ping | X you set |
| AI provider credit about to run outYour prepaid AI credit runs out at 2 a.m. and the main feature of your product stops answering. Users wake up to a broken app. The sensor sees the credit running low and reminds you days before it is empty. | A feature that stops tomorrow | Probe | No limit to set |
| Average AI response time above X secondsYour AI answers start taking so long that users stare at a spinner and close the tab. Nothing is technically broken, so nothing alerts. The sensor tracks the average wait and tells you when it gets too long. | Users kept waiting | Probe | X you set |
| Empty or cut-off answers above X%A prompt change makes the model cut its answers short or return nothing at all. Users get half a reply and assume the product is unfinished. The sensor counts empty and cut-off answers and alerts you when they rise. | Quality that dropped | Ping | X you set |
| A model you use retires within X daysThe model your app calls is retired on a date its provider announced months ago. On that day your feature simply stops. The sensor counts down to the date you keep with the model name and reminds you while switching is easy. | A break you can see coming | Probe | X you set |
| AI endpoint open without sign-in Part of the Guard Pro watchYour AI endpoint answers anyone, signed in or not. A stranger finds it and runs their own tool on it, billed to your account. The sensor checks that the endpoint asks for a sign-in and alerts you if it is open. | Usage billed to you | Pull | No limit to set |
| AI key in the code browsers receive Part of the Guard Pro watchYour AI key ships inside the code every visitor's browser downloads. Someone copies it and runs up a bill in your name. The sensor looks for the key in your public code and tells you the day it appears. | A key that leaked | Pull | No limit to set |
| AI provider outageYour AI provider has an outage and your support inbox fills with users asking what you broke. The sensor reads the provider's status and tells you at once, so you can post a short notice instead of searching your own code. | A feature failing through no fault of yours | Providerprovider status page | No limit to set |
| AI requests above X an hourA script starts hitting your AI feature thousands of times an hour. By the time you notice, the bill is large and the feature is slow for everyone. The sensor sees the jump in requests and alerts you within the hour. | A usage spike or an attack | Ping | X you set |
| Content filter blocks above XAfter an update your content filter blocks ordinary questions, and users get refusals for normal work. Or someone is probing it for misuse. The sensor counts the blocks either way and tells you when they rise. | Misuse, or a filter set too strict | Ping | X you set |
| Document search (vector) returns resultsYour document index is wiped in a migration, and your assistant now answers without any of your knowledge. It sounds confident and it is wrong. The sensor runs a search that should find something and tells you when it finds nothing. | An index that was deleted or is empty | Probe | No limit to set |
| Documents waiting for processing above XNew documents pile up waiting to be processed, so your assistant never learns what customers just uploaded. They ask about it and get nothing useful. The sensor sees the backlog grow and tells you before they ask twice. | Embedding work that is stuck | Probe | X you set |
| Average cost per AI chat up X%A small prompt change quietly adds a long block of text to every request. Each chat now costs several times more, and nobody notices until the invoice. The sensor watches the cost per chat and tells you after the first day. | A prompt that grew after an update | Probe | X you set |
| 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. | Cost with no ceiling | Ping | X you set |
| An MCP server the app uses answersAn outside tool your AI relies on goes down, and your feature fails in ways that look like your own bug. You lose hours searching the wrong place. The sensor checks that the tool answers and tells you where the problem really is. | An outside tool that is down | Provider7Maps data | No limit to set |
| The system prompt changed in a deployA deploy overwrites the instructions behind your AI feature with an old test version. Your assistant suddenly talks to customers like a developer's draft. The sensor notices the instructions changed and tells you right after the deploy. | An unintended change in behavior | Probefingerprint only | No limit to set |
| Negative user feedback (thumbs down) above X%After an update your AI's answers get worse and users start pressing thumbs down. Most never say why; they just stop asking. The sensor watches the share of negative feedback and tells you when it climbs. | Quality that dropped | Ping | X you set |
By connection method
How the library connects.
Sensors per category and connection method. A sensor that can use two methods counts in both.
| Category | Pull | Ping | Probe | Provider | Sensors |
|---|---|---|---|---|---|
| Online store | 8 | 3 | 9 | 2 | 22 |
| Suspicious silence | 1 | 9 | 10 | 2 | 21 |
| Databases and data | 2 | 3 | 15 | 3 | 20 |
| Background jobs and integrations | none | 12 | 8 | 1 | 21 |
| SaaS and users | 6 | 4 | 11 | none | 20 |
| AI features | 2 | 6 | 10 | 2 | 20 |
| All | 19 | 37 | 63 | 10 | 124 |
Pull Guard checks your app
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
Ping Your app pings Guard
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
Probe Signed probe in your app
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
Provider Read-only provider connection
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
The probe endpoint
A signed check that runs inside your app.
One address in your app, such as /api/guard-probe, added by your AI from the probe kit for your stack: Next.js, Supabase Edge Functions, Express or Python.
- Signed requests only. It answers only a request signed (HMAC) with your app's own key, refuses anything unsigned, altered or stale, and signs its answer the same way. You can replace the key in one click.
- Read-only checks you approved. It uses the connection your app already has and runs only read-only checks you confirmed. The queries live in your code, not with 7IT.
- Status and numbers, never rows. The answer holds a status and numbers. Never rows, never user data, never secrets. Its size and shape are limited.
- Rate-limited. It limits how often it can be asked.
- An open format. The answer follows the shape of the IETF draft "Health Check Response Format for HTTP APIs": an overall status of
pass,warnorfail, and checks namedcomponent:measurementwith an observed value and unit.
An answer, with sample values
HTTP/1.1 200 OK
Content-Type: application/health+json
{
"status": "pass",
"checks": {
"database:responseTime": [
{ "observedValue": 41, "observedUnit": "ms", "status": "pass" }
],
"orders:lastCreatedAge": [
{ "observedValue": 37, "observedUnit": "min", "status": "pass" }
],
"jobs:queueDepth": [
{ "observedValue": 3, "observedUnit": "jobs", "status": "pass" }
]
}
}
The ping address
For jobs that should report in.
Each ping sensor has its own private address that cannot be guessed. A ping that does not arrive on time is the alert.
- <ping-url>
- Success: the job ran.
- <ping-url>/start
- The job started. Guard measures how long it runs and notices a job that started and never finished within your limit.
- <ping-url>/fail
- The job failed.
- <ping-url>/<exit code>
- The job's exit code: 0 is success, anything else is a failure.
- <ping-url>?n=<count>
- One check-in that stands for several events, 1 to 10,000, for example the runs of a function since its last check-in. It counts as one check-in toward your hourly number, so sending once a minute with a count is welcome. Sensors that count events compare the count with a number you set, or with the normal pace Guard learns from your own first 3 days.
- Grace
- How long after the expected time Guard waits before it alerts. You set it; Guard suggests it from the job's own history.
- How often
- Each plan keeps a set number of check-ins an hour (see the plans), and the Faster pulse add-on doubles it. A check-in over that number is not recorded: it gets
429 Too Many Requestswith a plain reason and aRetry-Afterheader. Report at the moments that matter, such as the start and the end of a job. - When it counts
- Check-ins are gathered and saved together. A failure or a missing check-in is acted on at the next regular check of your site, not the instant it arrives.
In a scheduled job
# the job started
curl -fsS -m 10 <ping-url>/start
# the job ran: report its exit code (0 is success)
./nightly-email.sh
curl -fsS -m 10 <ping-url>/<exit code>The address can be replaced in one click. Incoming pings are rate-limited.
MCP tools
The tools your AI uses.
New tools on the 7IT Guard MCP server, also available as a regular API with your 7IT key.
- propose_sensors
- Takes what you want watched, in words, and the app. Returns a proposed list of sensors in a fixed shape. Saves nothing.
- get_probe_snippet
- Returns a short probe endpoint for your stack (Next.js, Supabase Edge Functions, Express, Python) for your AI to add to the code. The signing key is never shown in the chat: you get a one-time link to open yourself.
- add_sensor
- Registers one sensor, only after you confirm it in the chat. Marked as a tool that changes state.
- test_sensor
- Runs the sensor once and shows what it will report when it watches.
- list_sensors, sensor_status
- What is watched, and how each sensor stands right now.
- pause_sensor, remove_sensor
- Pause or remove a sensor.
- planned_work
- Keeps alerts quiet while you update: from now for a while, or a window once or on a schedule, in your time zone.
Rules that always hold
- Your yes, every time. Your AI never registers or changes a sensor without your explicit confirmation in the chat.
- Paused until proven. A new sensor starts paused and turns on when its first check passes.
- Only your app. A sensor aimed outside an app whose ownership was proven, and its subdomains, is refused. Outside APIs, such as your payment provider, are checked through your own probe, not directly.
- No secrets in settings. A sensor setting that looks like a key or a password is refused when it is registered.
- Edit without AI. Pausing, renaming and removing a sensor also work from a simple screen in the control room. Adding one always goes through your AI, because it adds the code to your app.
This page describes what sensors do and how they connect. How Guard decides when to alert stays internal.
How sensors behave
Values, groups, flows, dependencies and planned work.
Six behaviours of Guard Pro, described as principles.
Several values per sensor
- Channels. A sensor reports one or more named values, each with a unit, such as answer time in ms and failed payments in %. One signed probe call can fill several values, because its answer already carries several checks.
- Two limits per value. Each value can have a warning limit and an error limit, in either direction (too high or too low). You set them, or approve the ones Guard suggests from your own history.
- The sensor shows its worst value. The sensor is as healthy as its least healthy value, and the alert names the value that crossed its limit.
- History per value. Every value keeps its own recent numbers, shown beside its two limits; the limits Guard suggests come from them.
Groups, tags, bulk edit and clone
- A tree. Site, then group, then sensor. A group can be a part of the business, such as Checkout, or a kind of work, such as Nightly jobs, and it can span your sites.
- Settings flow down. Where alerts go (as usual, or the inbox only), quiet hours, how serious an alert is, how often a sensor runs and how fast a page must answer can be set on a group and apply to every sensor in it. A setting on the sensor itself wins.
- Tags. Labels you choose, for filtering and bulk edit. A sensor can carry several.
- Bulk edit. One change applied to a selection, shown as a preview before it is saved, and recorded in the site’s timeline like any other change.
- Clone. Copies a sensor’s settings to another of your sites, or makes a second copy on the same site. A ping address and a probe key are never copied: the clone gets its own, and your plan’s sensors per site still apply.
Business process sensor
- Built from sensors you have. It combines existing sensors into one flow, such as sign-up, payment and the welcome email. It makes no requests of its own.
- Your rule. You choose whether every step must be healthy, or a number of them out of the whole.
- One light, one message. It alerts in its own name and says which step failed. The steps can keep their own alerts or leave the talking to the flow.
Auto-discovery
- From what Guard already knows. Suggestions come from the outside watch (the services your app uses, such as hosting, database, email, sign-in, payments and AI) and the numbers your signed probe already reports.
- Suggestions only. Each suggestion is a catalog sensor with its settings drafted. Nothing is added until you confirm it, the same rule as a sensor your AI proposes.
- Only your app. Discovery looks only at an app whose ownership was proven, and its subdomains. It never scans other hosts.
Dependencies
- Parents and children. A sensor can be the parent of others: the database is the parent of orders, sign-ups and the sync. The outside watch of the site is the parent of every check on it, and an outage at a provider you rely on is the parent of the checks that need it.
- One alert about the cause. While a parent is failing, its children’s results are still recorded, but their alerts wait. One alert names the parent and how many checks depend on it.
- Back to normal. When the parent recovers, each child alerts on its own again if it is still failing.
Maintenance windows
- Once or on a schedule. A one-off window with a start and an end, or a recurring one on chosen days and times, in your own time zone.
- Checks keep running. During a window every sensor keeps checking and recording; only the alerts wait.
- Nothing hides. If something is still failing when the window ends, the alert goes out then. Windows are marked on the site’s timeline and kept for the monthly SLA report.
- Where they apply. On a site: every check of the site waits together. Set from the control room app, or by your AI while it works (quiet for an hour).
Principles only. The exact rules Guard uses to decide when to alert stay internal, and may change as the feature is built.
In Guard Solo and Guard Pro
Custom sensors come with Guard Solo and Guard Pro.
Part of Guard Solo, Guard Pro and Pro + personal guidance. Prices are published when it opens.