Unknown
The server has not reported yet. We do not compare and we do not claim everything is fine — we simply say we do not know.
Monitoring and operations
Know what your AI is actually allowed to do
An MCP server gives AI access to company data. Operational monitoring shows whether it is running, how fast it responds and which tools it has enabled — and who changed what, and when.
Why you can trust it
We do not show a picture someone once typed in.
Most operational dashboards display whatever was filled in at deployment. Six months later something changes on the server — and the dashboard still shows green. That picture is worse than an empty field, because people believe it.
If we do not know, we do not claim.
| Situation | With us | Usually |
|---|---|---|
| Server does not report its tools yet | the portal says we do not know, and explains how to enable reporting | filled in by hand at deployment and never updated again |
| Availability with no measurements | shows a dash | shows 100 % — zero errors out of zero checks |
| A settings change | written to a trail that cannot be rewritten or deleted | a log that can be edited |
| Credentials | we do not store them at all, only a reference to where they live | “stored and managed securely” |
Approved versus actual
The server reports what it actually offers. We compare it with what was approved.
The list of permitted tools in our system is an agreement. On its own it does not guarantee the server sticks to it — so we ask the server, not the paperwork.
In sync
The tools on offer match the approved configuration, unchanged since the last check.
Drift
The server offers a tool that was never approved. The AI has access to something nobody agreed to — and you find out immediately.
An extra tool is a security event and is handled as an incident. A missing tool usually just means the latest configuration has not been deployed yet — visible in the portal, but it wakes nobody up.
Why it matters
An integration rarely fails loudly. It fails quietly.
Going live isn't the finish line, it's the start. These are the situations monitoring exists for.
The integration stops working and the company hears it from users, not from monitoring.
“The server is up” says nothing about whether its connection to the CRM or the mailbox still works.
Nobody knows exactly which tools the AI has access to, or when that last changed.
When something breaks, the first argument is about whose side the problem is on.
What monitoring covers
Four things you need to know about production.
We measure from the outside, independently of what the server claims about itself. You see the same numbers and records we do.
- 01
MCP server
your production
- 02
Measurement
every minute, from outside
- 03
Evaluation
threshold, duration, quiet mode
- 04
Incident
timeline and explanation
- Healthyresponds within the expected time
- Degradedresponds slowly or with errors
- Downnot responding
Status is never conveyed by colour alone — always with a label and a marker.
Availability and latency
A health check every minute from our infrastructure, independent of the server itself. Availability is tracked over 24 hours, 7 days and 30 days.
- a check every minute
- availability over 24 h / 7 days / 30 days
- latency including the 95th and 99th percentile
- an average on its own hides painful outages
Failures by cause
Failures are classified, not just counted. The difference between “the server isn't answering” and “it answers, but its CRM connection is down” decides who has to fix it.
- request timed out
- DNS or TLS failure
- authentication rejected
- the problem is in a downstream system
Permissions and configuration
Which MCP tools a server has enabled is recorded, versioned and approved. Every change shows who made it, when, what exactly differs from the previous version, and why.
- the list of enabled tools
- a version and an approval for every change
- the diff against the previous version
- credentials are never stored — only a pointer to where they live
Incidents
When something breaks, an incident is opened with a timeline. You see its status and an explanation — not our internal operational notes.
- a timeline of the event
- current status
- an explanation that makes sense outside IT
- cause and follow-up once it's resolved
What the customer sees
Your own access to the portal, not a PDF report once a month.
The portal is available whenever you want it. You can check how your integration is doing on a Sunday evening, without waiting for us to reply.
A customer only ever sees their own data. Separation between organisations is enforced in the application and in the database — not merely agreed in code.
- an overview of your own servers
- availability and latency charts over a period you choose
- the state of each system connection and the permission scope of each
- configuration history: who changed what, and when
- incidents with status and explanation
- an audit trail of changes in your organisation that cannot be altered retroactively
- settings for who gets alerted, and at which severity
How an outage is handled
From detection to explanation in four steps.
- 01
Detection
The check runs every minute, so a problem surfaces before a user gets round to reporting it.
- 02
Evaluation
An alert is raised once the condition holds for a while — not after a single dropped packet. Repeated reports of the same problem are grouped.
- 03
Alerting
By email or webhook, according to the severity you set. During planned maintenance no alarm is raised.
- 04
Incident
Serious problems open an incident, with progress recorded as it goes. Once resolved, the cause and the follow-up are added.
Monitoring doesn't prevent outages. It shortens the time before anyone knows about one — and removes the guesswork about what actually happened.
FAQ
What we're asked about monitoring.
Do we have to install anything?
The basic measurement runs from the outside; nothing needs to be added on your side. If you want more detailed metrics, the server can report them itself.
Can you see our data?
No. Monitoring tracks availability, latency and error rates. Email contents, CRM records and personal data are never stored in it.
Who hears about an outage first, you or us?
Alerts go to both sides at the same time. You decide who is notified, and from which severity.
Can you monitor a server we built ourselves?
Yes, as long as it is reachable over HTTPS. It doesn't have to be a server we delivered.
What if we want to stop?
The data stays yours and monitoring can be switched off. It doesn't tie you to anything else.
Tell us what you run and we'll go through what is worth watching.
Not everything needs measuring. In the initial consultation we agree what is critical for you and what only needs an eye kept on it.
Go to the enquiry form