Monitoring
MCP server monitoring, and expiry you hear about first
An MCP server that stopped answering three weeks ago looks exactly like one that is fine, until an agent answers from memory nothing has refreshed since.
What breaks, and how you find out today
A connected server fails quietly. A token is rotated, a scope is withdrawn, a URL moves, a tool is renamed. Nothing errors on your screen, because nothing was on your screen.
The cost lands later. Your agent keeps answering, from context that was true when it was last read, and nobody knows which answers those were.
What Contextely does
Checks every source on a schedule
It opens the connection, lists the tools, and confirms the ones your source is configured to call are still there under the names it uses. Latency is recorded with each check.
Tells your admins when one stops
Once, on the second consecutive failure. One failed check is usually the network, and a person emailed about those stops reading the emails.
Separates a dead sign-in from a dead server
A refused refresh is not a timeout, and it needs a person rather than patience. That one is announced immediately, with the button that fixes it.
Warns before an authorization lapses
Only where the deadline is real. See below: this is the part most monitoring gets wrong, and getting it wrong is worse than saying nothing.
Why we do not warn you about most token expiry
An OAuth access token usually lives about an hour. It is exchanged silently on the next refused request, and the expiry date you can see moves forward without anybody doing anything.
Alerting on that is an hourly warning about something that was never going to break. The recipient builds a filter rule inside a day, and then the one message that mattered is filtered too.
An authorization with no refresh token
Some providers issue only an access token. Nothing can exchange anything, so that expiry is the real deadline and a person has to sign in again.
A client registration with an end date
Authorization servers may put one on a dynamic registration. Existing tokens keep working for a while, which is exactly what makes it worth saying in advance.
A token that renews itself
It renews. You hear about it when a refresh is actually refused, which is a different message with a different fix.
A pasted token whose lifetime we were not told
We could ask an admin to type the date. Nobody updates it on rotation, and a confident warning about a credential that is already fine is worse than silence.
What happens to your memory while a source is down
It is still served, and still labelled with its own age. Nothing is deleted and nothing silently becomes less true. What stops is the refresh that keeps it honest.
That labelling is the same freshness contract every memory object carries, whether or not anything is wrong. How the MCP layer works covers the rest of it.
Where you see it
On the sources page, with the recent checks and their latencies, because a server that still answers in nine seconds is failing in a way no badge reports.
Also on the API and the MCP surface. sources_list reports health, the last check and any known expiry, so an agent can weigh what it is being told.
Under a partner agreement nothing is emailed to your clients. The state reaches you through the organization API and a signed callback, and you tell them in your own words.
Self-hosting
The sweep is an ordinary scheduled route guarded by a shared secret. Point any scheduler at it, or leave it off: an unchecked source reports itself unchecked rather than healthy.
The reference has the states, the schedule and the exact conditions that send mail. Self-hosting covers the rest, or write to hello@contextely.com.