Grounds watches your systems, finds the problem and fixes it.
Your apps, your network and your data on one screen. It explains what broke in plain words, fixes what it safely can, and phones you when it matters. Nothing ever leaves your building.
- On-premise
- Your data stays yours
- Local AI, no cloud
- Enterprise ready
Go on. Break production. You're on call tonight.
Press the button to take the payments database down at 03:21. Grounds will find it, explain it and phone you. Answer, and decide. On the right, the same night with ordinary monitoring.
Simulated clock
03:21:00
With Grounds
checks every 30 sEverything is quiet. Press the red button when you’re ready.
Ordinary monitoring
exampleThe same night, with dashboards and an alert email.
A simulation of one incident. The clock runs at 8x. The ordinary-monitoring lane is an example of a manual response, not a measurement.
Your monitoring says something is slow. Then a person starts reading.
Ordinary monitoring stops at the alert. Someone gets woken up, opens one tool after another and pieces the story together by hand, while the problem keeps costing money.
p95 latency · payments
ERROR pool exhausted, waiting
WARN retry 1 of 3
ERROR timeout after 30000 ms
payments-api-7f9Running
payments-api-2c1Restarting
orders-5d8Running
⚠ High latency on payments-api
p95 above threshold for 5 minutes. No cause attached. No suggested action.
Connections in use
20 / 20
Which query? Which caller? No idea.
CPU 41% · Memory 63%
Everything looks normal here.
Ops anyone awake? payments look bad
Dev checking the dashboards…
Ops is it the database or the app?
Dev no idea yet
- 1An alert firesA threshold trips. The email says what, never why.
- 2Someone is woken upThe on-call engineer reads it on a phone, half asleep.
- 3Seven tabs, one guessDashboards, logs, pods, database, cloud. The story is pieced together by hand.
- 4A fix typed at nightA restart or a config change, done by hand.
- 5Nobody checks it heldAnd next time starts from zero again.
Traditional monitoring· Detects an alert· Manual investigation· Engineer fixes· No verification
Dashboards end where Grounds begins.
Everything your team needed seven tabs for, on one screen and already explained. Click a widget, or drag it onto the second screen, to open it in full.
Overview
Live · updated 1 s ago
Databases
Full-screen view · live
Databases
Pools, slow queries and locks, explained
payments-db-01 · connection pool
Postgres 15 · primary · 24 hours
Pool full since 03:16. Payment queries queue for 882 ms each.
Who holds the connections
Right now
Slowest queries
By total time, last 15 min
Other databases
All healthy
Postgres · 7/20
MongoDB Atlas · 3 replicas
Redis · 96% hit rate
Example data from a simulated bank, to show what Grounds puts on screen.
The idea, in one line
It's like having your best engineer watching every system, 24 hours a day. One who never sleeps, never misses anything, and phones you the moment it matters.
03:24:00
checked every 30 s
Never sleeps
Checks every service, server and database every 30 seconds, all night, every night.
42 of 42 watched
Never misses
Watches everything at once, not just the dashboard someone left open.
Why payments are slow
A batch job is holding the accounts table, so payment queries wait.
Explains itself
Says what broke and why, in plain words, with the proof attached.
Phones you
When a database goes down at 3 a.m., it makes a real phone call and waits for your answer.
No dashboards to stare at. No inbox to watch. Grounds does the watching.
Seven agents, one loop, every thirty seconds.
Watch without touching anything, decide every 30 seconds, act, then check the action worked. Nothing in the loop needs a change to the apps being watched.
next check in
30s
The seven agents
- 01WatchmanDetectCompares live signals with learned baselines and thresholds.
- 02InvestigationGatherPulls the traces, pool state, errors and recent deployments around the issue.
- 03RCAExplainWeighs the evidence and writes a root cause with a confidence score.
- 04FixActPlans the fix, runs safety checks and hands it to the isolated executor.
- 05MemoryLearnSaves the resolution as a pattern, so the next one is faster.
- 06NotifyEscalateMakes sure someone is told, and escalates anything nobody answers.
- 07BotAnswerAnswers questions in plain language, with links to the evidence.
At 3 a.m., an email is not an alert.
When a database stops answering, Grounds phones the on-call engineer, explains what's happening, listens to the reply and, once they say yes, restarts it and confirms the recovery before hanging up.
Grounds Alert
Calling the on-call engineer · 00:14
What Grounds is acting on
- Database
- payments-db-01
- Not responding for
- 3m 12s
- Payments failing
- 100%
- Answer understood as
- …
- Resolved in
- …
It answers questions back
Ask about the batch job and you get a real answer, because Grounds already knows.
It can't improvise
Restart or hang up. Those are the only two things it's ever allowed to do.
It proves the fix
It doesn't just say done. It checks twice and agrees with its own monitoring first.
Automation on a short leash.
Grounds fixes things itself, but only inside limits you set. Small config changes run on their own, code changes wait for a named approval, and architecture is only ever a recommendation.
Now
Configuration changes
Grounds applies these itself, within rate limits per tenant.
e.g. Give payments more connections
✓ Grounds acts
This week
Code-level fixes
Queued for a named person to approve before anything runs.
e.g. Move the batch job to 23:00
◐ You approve
This sprint
Architecture
Written down as a recommendation. Never applied automatically.
e.g. Separate the two workloads
○ You decide
The path every automatic fix takes
- POOL_RESIZE01
Fix plan
by horizon
- 02
Safety gates
pre-checks, maintenance windows
- 03
Signed
command signed in the backend
- 04
Audit first
written before it runs
- 05
Fix executor
isolated process, allowlist only
- 06
Prove it
5 recovery checks
The executor only accepts:
CREATE_INDEXPOOL_RESIZETHREAD_POOL_RESIZETIMEOUT_CONFIGCACHE_CLEARGC_TRIGGERRATE_LIMITRecovery checks, matched to the change
- Trace p95 recovery
- Database health
- Pod restarts stop
- Deployment ready
- Log patterns clear
✓ Recoveredor↺ Rolled back
Before and after metrics are kept either way.
Nothing leaves your building.
Telemetry, models, embeddings and speech all run inside your infrastructure. There's no cloud dependency to switch off, because there isn't one.
Your apps, servers and databases
Not touched, not changed, not slowed down. Watched from the outside.
Zero-touch collectors
eBPF observer
kernel-level capture
OpenTelemetry
any OTel service
Discovery agent
finds what's running
JVM agent
method-level detail
Grounds
One Linux host or your Kubernetes cluster. Detect, explain, decide, act.
Cloud AI services
never called
Models on your hardware
Reasoning
llama3.1:8b
Code
qwen2.5-coder:7b
Embeddings
nomic-embed-text
Voice decisions
qwen2.5:3b
Speech on CPU
Speech to text and back runs inside the deployment. No audio goes to a third party.
No telemetry, prompt or embedding is sent out.
Built so an auditor can follow it
- ✓Data residencyTelemetry, models, embeddings and speech all run inside your infrastructure.
- ✓Immutable auditA signed record is written before any automated action, and never rewritten.
- ✓Human gatesCode-level fixes wait for a named approval. Architecture is never applied automatically.
- ✓Small blast radiusFixes run in an isolated, allowlisted process and reverse if the check fails.
- ✓Sensitive dataIdentifiers are masked in answers, with a report on what the collectors capture.
- ✓Honest reportingWhere a number can't be worked out from real data, the screen says so.
One Linux host
Eight containers from one compose file. 8 vCPU, 24 GB RAM, 250 GB SSD. Offline image bundle for air-gapped sites.
Your Kubernetes cluster
A Helm chart, with the observer and discovery agent running as DaemonSets.
Forty capabilities. One platform.
0/ 40 capabilities
One database, one login and one bill. Everything below is running in the product today.
01
Monitor
See everything, live.
- ✓Infrastructure
- ✓Containers and Kubernetes
- ✓Application performance
- ✓Databases
- ✓Log management
- ✓Network and dependency maps
- ✓AWS cloud
- ✓MongoDB Atlas
- ✓Service discovery
- ✓Real-time pulse
02
Investigate
Find the real cause.
- ✓Distributed tracing
- ✓API and endpoint monitoring
- ✓Root cause analysis
- ✓Blast radius
- ✓Behaviour profiles
- ✓Trend analysis
- ✓Business flow tracking
- ✓Code intelligence
- ✓Institutional memory
- ✓Ask in plain language
03
Respond
Act fast, fix with confidence.
- ✓Smart alerts and thresholds
- ✓Incident management
- ✓Email and Slack
- ✓On-call schedule and escalation
- ✓Call on duty (voice)
- ✓Automated remediation
- ✓Approval workflow
- ✓Rollback and verification
- ✓Maintenance windows
- ✓Audit trail
04
Operate
Built for your environment.
- ✓Zero-touch instrumentation
- ✓OpenTelemetry native
- ✓Local AI, no cloud
- ✓Data retention control
- ✓Role-based access
- ✓Multi-site and multi-environment
- ✓On-premise deployment
- ✓Kubernetes deployment
- ✓Executive and business reports
- ✓Compliance reports
Every digital business needs Grounds
Technology and SaaS
Cloud, microservices, digital platforms
Healthcare
Hospital systems, PACS, clinical apps
Financial services
Core banking, payments, digital channels
Telecom
Network services, customer platforms
E-commerce
Marketplaces, transaction systems
Grounds: your questions.
Do we have to change our applications?
No. Grounds watches from the outside using kernel-level capture, OpenTelemetry and lightweight agents, so an app that was never instrumented still shows up the moment it serves a request.
Does any of our data leave our network?
No. Telemetry, AI models, embeddings and even the speech for voice calls run inside your infrastructure. There's no cloud dependency to switch off, because there isn't one.
Will it change things in production on its own?
Only small, configuration-level fixes from a strict allowlist, like resizing a connection pool or creating an index, within limits you set. Code-level fixes wait for a named approval, architectural changes are recommendations only, and every fix is checked afterwards and rolled back if it didn't work.
What does it need to run?
One Linux host (8 vCPU, 24 GB RAM and 250 GB SSD recommended) or your Kubernetes cluster. Internet is needed once to pull images, or you can use an offline bundle for an air-gapped site.
Want to see it on your systems? Book a live demo.
Tell us a little about your setup. We'll reply within one business day to arrange a walkthrough.
- Weekly demos
- No lock-in
- You own the code
- 1 business day