Forem: Immanuel Gabriel

Making Ops Pulse less project-specific and more useful for Cloudflare builders

Immanuel Gabriel — Tue, 19 May 2026 16:04:16 +0000

I built Ops Pulse because I needed a calmer way to diagnose my Cloudflare setup.

When you are running Workers, D1, cron schedules, and logs across a few small services, the hard part is not always “getting metrics.”

The hard part is knowing what the metrics mean.

A Worker can look scary because an old error is still inside a long report window.

A cron job can look broken when it simply was not expected to run yet.

A service can be idle without being unhealthy.

A feed can be healthy but quiet.

And sometimes the thing you are about to edit is not the thing that is actually failing.

That is the loop Ops Pulse is meant to reduce.

Cloudflare metrics in.
Plain-English diagnosis out.

What Ops Pulse does

Ops Pulse is a local-first CLI for diagnosing Cloudflare Workers, D1, cron schedules, and Workers Observability logs.

It runs on your machine, uses your own Cloudflare token, and produces readable reports about what looks healthy, degraded, idle, noisy, or unknown.

You can run it with npx:

npx freshcontext-ops-pulse --help

Or install it globally:

npm install -g freshcontext-ops-pulse
freshops --help

The tool is designed for people who want a quick operational read before they start changing code.

It can help inspect things like:

Worker request counts
error rates
invocation status
runtime exceptions
client disconnects
CPU and wall time
subrequests
D1 reads and writes
D1 latency
cron behavior
Workers Observability events
recent logs for a specific Worker
plain-English recommendations

Example commands:

freshcontext-ops-pulse report --hours 1
freshcontext-ops-pulse report --hours 6
freshcontext-ops-pulse logs --worker my-worker --hours 1
freshcontext-ops-pulse errors --worker my-worker --hours 24
freshcontext-ops-pulse assays

The goal is not to replace Cloudflare Observability.

The goal is to sit one layer above the raw signals and help answer:

What is actually broken?
What is healthy?
What is idle?
What is old noise?
What should I inspect first?
What should I avoid touching?

That last question matters a lot.

A surprising amount of debugging time is wasted changing healthy systems.

Local-first setup

Ops Pulse does not require a hosted dashboard.

It does not require an account with FreshContext.

It does not send your Cloudflare metrics to my server.

It reads from Cloudflare using the credentials you provide locally.

Required environment variables:

CLOUDFLARE_ACCOUNT_ID=
CLOUDFLARE_API_TOKEN=

The token should be read-only where possible.

The current docs explain recommended Cloudflare token permissions, but the basic principle is simple: only give Ops Pulse access to the Cloudflare resources you want it to inspect.

For example, if you only want it to inspect Worker analytics and logs, scope the token around that.

If you want it to inspect D1-related signals, include the relevant D1 read permissions.

Do not commit your .env.

Do not paste your token into issues, chats, or support threads.

That privacy boundary is now documented more clearly in PRIVACY.md.

Diagnostic assays

I also cleaned up the diagnostic assay documentation.

An assay is just a focused check that asks one operational question.

For example:

Do public/runtime versions agree?
Do MCP clients see the expected tools?
Is cache behavior visible enough to trust?
Was cron expected in this time window?
Is the Worker actually throwing runtime errors?

Each assay should return a simple shape:

status
reason
evidence
recommendation

The statuses are intentionally boring:

healthy
warning
degraded
unknown

The unknown state is important.

A diagnosis tool should not fake certainty.

If Ops Pulse cannot see enough evidence, it should say that clearly instead of pretending everything is fine.

For example, a cache correctness check should not claim the cache is healthy if cache metadata is not visible in logs. It should explain what is missing and what visibility would be needed to make the call.

That is the kind of behavior I want from the tool generally.

Not dramatic.

Not magical.

Just honest.

What changed in this patch

This was a documentation and onboarding patch, not a feature rewrite.

The latest cleanup added or improved:

a clearer README
generic setup for non-FreshContext users
better quickstart examples
environment variable guidance
recommended token-permission notes
PRIVACY.md
docs/ASSAYS.md
safer .env.example comments
clearer CLI help text

The README now frames Ops Pulse as a local Cloudflare diagnosis CLI first.

My own systems are just the first place I used it seriously.

That matters because the tool should be useful to someone running their own Worker, API, cron job, D1-backed app, feed service, or MCP server.

Who this is for

Ops Pulse is probably useful if you are:

running Cloudflare Workers
using D1
relying on cron schedules
checking Workers Observability logs
maintaining a small API or feed
building an MCP server on Cloudflare
debugging alone without a full observability stack
trying to tell fresh failures from stale noise

It is especially useful when you want a quick answer before touching code.

Sometimes the right answer is:

Do not edit this Worker.
The errors are old.
Cron was not expected in this window.
This other service is the one to inspect.

That kind of answer can save more time than another graph.

What it is not

Ops Pulse is not auto-remediation.

It does not patch your Workers.

It does not deploy anything.

It does not mutate Cloudflare resources.

It does not replace Cloudflare’s own dashboards.

It is also not trying to be a full observability platform.

The current version is intentionally small:

local CLI
read-only diagnosis
plain-English reports

That is enough for now.

Current status

Ops Pulse is live on npm.

It has crossed a small first signal of interest, with a little over 100 npm downloads at the time I checked.

That is not product-market fit.

But it is enough of a signal to keep polishing the setup, docs, and diagnosis flow.

npm:

https://www.npmjs.com/package/freshcontext-ops-pulse

GitHub:

https://github.com/PrinceGabriel-lgtm/freshcontext-ops-pulse

Try it:

npx freshcontext-ops-pulse --help

Or:

npm install -g freshcontext-ops-pulse
freshops --help

The next useful work is probably still small:

better markdown/json output
clearer resource selection
more diagnostic assays
more sample reports
a simple setup check
stronger examples for non-FreshContext projects

I am trying to keep the direction simple:

Cloudflare metrics in.
Plain-English diagnosis out.

If Ops Pulse helps one other builder avoid chasing stale noise or editing the wrong service, that is already useful.

The part after shipping an MCP server: making it fail honestly

Immanuel Gabriel — Wed, 13 May 2026 11:25:06 +0000

I thought the hard part was shipping the MCP server.

It was not.

The hard part started after the server was public, listed, installable, and testable outside my own machine.

FreshContext is my MCP project around freshness-aware retrieval. The basic idea is simple: agents should not treat stale information as current truth. Every retrieved signal gets wrapped with source, timestamp, retrieval time, and confidence metadata, then ranked with freshness decay before it reaches the model.

That was the first public story.

But once the site, npm package, MCP Registry entry, Agentic Market listing, and feed APIs were live, a different kind of work became more important:

Making the system fail honestly.

The bug that bothered me most

A read-only QA pass found several issues.

Some were normal integration problems:

one finance path was failing against Yahoo with a 401
the Hacker News tool rejected plain text even though the product copy implied search-like behavior
one HN scrape path produced a malformed timestamp
the local stdio package reported an old internal version

Annoying, but fixable.

The serious issue was different.

A failed finance call could still be wrapped as high-confidence output.

That is poisonous for a product about freshness and retrieval trust.

If a tool fails, it should not come back dressed as:

Confidence: high
Score: 100/100

That is worse than an obvious crash. A crash tells you something broke. A confident bad envelope quietly teaches the user to distrust the whole system.

So the next release was not about adding features.

It was about making failures honest.

The 0.3.17 release

The 0.3.17 patch focused only on validated problems.

No new verticals. No redesign. No “while we are here” expansion.

The finance adapter moved away from the broken Yahoo path and now uses Stooq as a no-key quote source.

Failure-looking adapter output is blocked from becoming high-confidence FreshContext output.

The Hacker News tool now accepts both URLs and plain text queries while keeping the same field name for compatibility.

HN dates are normalized before freshness scoring.

The Worker version, npm package, stdio server info, and MCP Registry metadata were aligned to 0.3.17.

I also added a small stdio smoke test so the package can prove the basics before release:

initialize works
server version matches package version
tools/list returns 21 tools
key tools exist

None of this is glamorous.

It is the maintenance layer that makes the public product feel less fragile.

The release gate became boring on purpose

The release flow became:

build locally
smoke stdio
check Worker TypeScript
deploy Worker
smoke live MCP endpoint
verify npm registry install
update public metadata

That order matters.

I did not want to publish npm and then discover that the deployed Worker path behaved differently. I also did not want the registry, npm package, and website telling three different stories.

The rule became:

Do not publish or update public surfaces until the live path works.

This is obvious in hindsight.

It is also exactly the kind of obvious thing that gets skipped when you are moving fast.

Why I built Ops Pulse

Around the same time, I built a small tool called FreshContext Ops Pulse.

It is not a dashboard. It is not a giant observability product. It is a local-first TypeScript CLI that reads Cloudflare metrics and turns them into plain-English diagnosis.

FreshContext runs across Cloudflare Workers, D1, cron, and a few small feed services.

That creates a practical debugging problem.

If the Fresh HN Feed is healthy, I should not touch it while debugging the MCP worker.

If the Jobs Feed is idle because no cron was expected in that window, that is not an outage.

If the MCP core has runtime exceptions, I need to focus there instead of randomly changing healthy systems.

Ops Pulse gives me that separation.

The pipeline is simple:

Cloudflare metrics -> normalized snapshot -> diagnosis -> recommendation

That helped shift the project from “poke around until something changes” to “debug from evidence.”

That is a major relief when you are solo-building and every fix can accidentally create two more bugs.

The real lesson

The biggest lesson was not about MCP specifically.

It was about consistency.

If the website says 21 tools, the registry should say 21 tools.

If npm says 0.3.17, the Worker should report 0.3.17.

If a source has a timestamp, normalize it before scoring.

If a tool fails, make the failure visible.

If one service is healthy, do not disturb it while fixing another service.

This sounds boring because it is boring.

But boring is what makes a tool usable.

A lot of early product work feels like building features. Then the product becomes public and the work changes. Suddenly the important thing is not “can I add one more thing?”

It is:

Can I trust the thing that already shipped?

For FreshContext, that meant stopping feature work for a moment and stabilizing the public surface:

MCP Worker live
npm package verified
MCP Registry updated
Agentic Market listing accepted
Fresh HN Feed live
Fresh Jobs Feed live
Apify actors published
Ops Pulse available for operational diagnosis

There is still plenty to improve.

But the project is now past the “just an idea” phase. It has install paths, public listings, live feeds, and a small ops loop watching the system.

That feels like a better foundation than another rushed feature.

Links

FreshContext hub:

https://freshcontext-site.pages.dev/

Live demo:

https://freshcontext-mcp.gimmanuel73.workers.dev/demo

MCP endpoint:

https://freshcontext-mcp.gimmanuel73.workers.dev/mcp

GitHub:

https://github.com/PrinceGabriel-lgtm/freshcontext-mcp

Agentic Market:

https://agenticmarket.dev/princegabriel73/server

The next step is not more feature sprawl.

It is better distribution, evidence-led debugging, and watching which surfaces people actually use.

I’m also testing a few FreshContext reviews this week. If you’re shipping an AI tool, MCP server, repo, launch page, or retrieval workflow, I can check for stale-context risk, broken public surfaces, weak provenance, version mismatches, and failure states that look too confident.

Email: gimmanuel73@gmail.com

Building FreshContext: Temporal Intelligence Infrastructure for AI Systems

Immanuel Gabriel — Mon, 11 May 2026 20:59:57 +0000

I’ve been building something called FreshContext.

The core idea is simple:

AI systems often treat fresh and stale retrieved information as equally useful.

FreshContext is an attempt to fix that.

Instead of only retrieving information, the system applies temporal scoring before signals reach an LLM or agent workflow.

That means:

source timestamps matter
decay matters
provenance matters
retrieval timing matters

What I built so far

1. FreshContext MCP

A Cloudflare-native MCP server with 21 tools focused on freshness-aware retrieval and live intelligence workflows.

Current stack:

Cloudflare Workers
D1
KV
structured JSON envelopes
freshness scoring
observability tooling

GitHub:
https://github.com/PrinceGabriel-lgtm/freshcontext-mcp

2. Fresh HN Feed

A freshness-ranked Hacker News signal feed.

Instead of simply listing posts chronologically, the feed scores signals using temporal decay and relevance weighting.

GitHub:
https://github.com/PrinceGabriel-lgtm/fresh-hn-feed

3. Fresh Jobs Feed

A freshness-ranked jobs API built on public job sources.

The current focus is AI/ML-oriented roles, but the architecture is designed for broader signal ingestion later.

GitHub:
https://github.com/PrinceGabriel-lgtm/fresh-jobs-feed

Live API:
https://fresh-jobs-feed.gimmanuel73.workers.dev

4. Ops Pulse

One thing I learned quickly:
observability matters.

I built a separate operational analysis tool for monitoring:

Workers
D1
cron ingestion
runtime failures
cache behavior
external API failures

The biggest improvement so far wasn’t a new feature.

It was finally seeing the actual failure patterns clearly.

What surprised me

The hardest part wasn’t generating responses.

It was:

freshness correctness
runtime isolation
cache correctness
partial failure handling
observability
temporal consistency

The infrastructure side of AI systems is much deeper than I expected.

Current direction

The long-term goal is turning FreshContext into a broader temporal intelligence platform:

freshness-aware feeds
agent retrieval infrastructure
signal marketplaces
operational intelligence
temporal ranking APIs

Still very early.
But the architecture is finally starting to stabilize.

If you’re building retrieval systems, agents, MCP tooling, or Cloudflare-native AI infrastructure, I’d genuinely love to connect and learn from others working in this space.