Pulse is now NeverBlink.
The scope of what we're building has changed. This is the beginning of our next chapter, and our aim is an ambitious one: to transform how live, mission-critical production databases are maintained, operated, and improved.
We built Pulse for Elasticsearch and OpenSearch. We knew these technologies deeply after spending more than a decade building, scaling, optimizing, and rescuing search clusters in production. Across all that work, we kept seeing the same pattern. Capable engineering teams were losing too much time to dashboards, ambiguous alerts, performance regressions, and fires that could have been caught much earlier.
Pulse was built to address that. It gave teams a clearer view of cluster health, surfaced risks before they turned into incidents, and translated years of specialist knowledge into practical recommendations. Pulse saved countless hours debugging slow clusters, helped teams avoid incidents, and provided peace of mind for SRE, Platform and DevOps teams all around the world.
As the platform grew, though, it became clear that the problem was bigger than search.
The same operational burden exists across the database layer. Every engine has its own internals and failure modes, but the day-to-day maintenance experience is surprisingly familiar: fragmented tooling, scarce expertise, reactive support, noisy alerts, manual investigation, and critical knowledge concentrated in the heads of too few people.
We think database maintenance is ready for a different approach. NeverBlink is our next step toward building it.
Database Maintenance Has Not Kept Pace
The way teams build and ship software has changed dramatically. Infrastructure is programmable, deployments are continuous, and applications scale across clouds and regions. AI is becoming part of everyday engineering work as well.
Database maintenance hasn't kept up. In many organizations, it still follows an operating model that feels increasingly out of date.
The sequence is all too common: a dashboard reports a problem, an alert wakes someone up, and several engineers begin correlating metrics, logs, query behavior, and configuration changes by hand. When the issue is difficult enough, the team has to find a specialist who understands that particular engine and can join the investigation.
Managed database services take away some infrastructure work. They don't remove the need to understand workloads, diagnose query regressions, control costs, figure out missing indexes, plan capacity, or make sound architectural decisions. General-purpose observability tools collect valuable signals, but rarely offer the engine-specific reasoning needed to turn those signals into the right action.
That leaves us with an uncomfortable contradiction. Databases are among the most critical and stateful parts of the stack, yet their maintenance remains one of its most reactive and expertise-dependent functions.
We want to change that model. The answer isn't another wall of charts, or a system that pretends every database works the same way. The work itself needs to change: periodic checks should become continuous maintenance, symptoms should lead to root causes, generic alerts should become precise recommendations, and prevention should replace emergency intervention whenever possible.
AI and Agents Make the Challenge Bigger
AI is speeding up software creation. Coding agents can generate a service, add a feature, change a schema, or create a new query path in a fraction of the time these tasks once took. As software becomes cheaper to create, teams will produce more applications, more services, more database instances, and much more database activity.
Agents work at machine speed, too. They can issue queries, launch workflows, and introduce changes more frequently than any human team. The opportunity is enormous, but so is the added operational surface area. There are more workloads to understand, regressions to catch, capacity decisions to make, and ways for a small mistake to reach production quickly. And of course, queries that are just AI slop that can take down your entire platform if not properly handled.
If we automate software creation without changing database operations, we simply move the bottleneck. Teams may ship faster, only to give that time back while investigating added cost, instability, and maintenance work at the data layer. Data platform maintenance was always a pain without eonugh experienced people to handle it; this gap is growing every day now.
Fortunately, AI also gives us a way to handle some of that pressure.
We expect AI agents to take an active role in database operations. They can investigate an alert, explain a query regression, check the effect of a deployment, propose a safe optimization, or bring the right context into an incident, all while an engineer remains in control. Rather than sending someone to a dashboard to piece together the story manually, an agent should be able to ask what changed, understand the evidence, and help move the issue toward resolution.
That requires much more than generic model knowledge. Agents need trusted, current, engine-specific context from the actual environment: health signals, queries, configuration, recommendations, and root-cause analysis. They also need clear permissions and accountable human oversight.
This is an important part of NeverBlink's mission. Through our API and MCP server, NeverBlink can bring live database intelligence into the tools and agent workflows engineers already use. Its proactive analysis can surface risks and begin an investigation before a person or agent even knows which question to ask. By combining AI with the judgment of experienced database engineers, it can also help teams tell the difference between a plausible answer and the right operational decision.
Humans and Agents should work from the same reliable operational context, with automation taking on the toil and people retaining control of the decisions that matter, and an ever watching eye to proactively diagnose and suggest changes before any real production issue hits.
From Monitoring to Continuous Maintenance
Monitoring can tell you that something changed. Maintenance should tell you why, whether it matters, what to do next, and how to keep it from happening again.
Doing that calls for a different kind of platform. It needs to continuously combine metrics, logs, queries, configuration, topology, and historical behavior with deep knowledge of the database engine. It should spot risks early, investigate anomalies, prioritize improvements, and explain its reasoning clearly enough for an engineer to act with confidence.
This is what we're building with NeverBlink:
- Continuous rather than periodic. Database health, performance, resilience, and cost should be evaluated all the time, not only during an incident or quarterly review.
- Proactive rather than reactive. The best incident is the one addressed while it is still a warning, before customers notice and before an engineer is paged.
- Actionable rather than merely observable. Teams need a diagnosis and a concrete next step, not another unexplained red graph.
- Automated but accountable. AI can carry more of the investigative and maintenance burden, while engineers retain visibility and control over consequential changes.
- Built for people and agents. Database intelligence should be available through the UI, APIs, and MCP so engineers and the agents working alongside them can reason from the same live context.
- Expert when it matters. Some situations still require judgment earned through years of operating databases in production. Automation and human expertise should reinforce each other.
Our ambition is to make the old model of database maintenance—fragmented dashboards, manual health checks, recurring fire drills, and emergency consulting—feel obsolete.
Going Beyond Elasticsearch and OpenSearch
Elasticsearch and OpenSearch are where our platform began, and they remain a core part of NeverBlink. We're proud of the expertise, tooling, and customer trust we've built around them. We aren't moving away from search. We're building outward from a strong foundation.
Modern engineering teams rarely run just one kind of database. Search and vector workloads might live on Elasticsearch or OpenSearch, real-time analytical workloads on ClickHouse, and transactional workloads on a relational database. Every system brings its own metrics, query patterns, operational risks, and maintenance practices. Each new engine adds another layer of complexity.
NeverBlink is expanding to reflect that reality. ClickHouse and PostgreSQL support is coming and available in private beta, and more database technologies will follow.
Breadth cannot come at the expense of depth. Reducing every database to the same generic CPU and memory charts would not work. A ClickHouse merge backlog is not an Elasticsearch shard-allocation problem, and neither can be understood from infrastructure metrics alone. NeverBlink is not a general-purpose AI SRE platform. It goes deeper, hence tackling one technology at a time.
We're building a common operating layer for database maintenance while preserving the engine-specific intelligence that makes its guidance useful: one place to understand the databases your product depends on, with analysis grounded in how each of them actually works.
Why NeverBlink?
Pulse was the right name for where we started. It described a signal, a way to understand the health of a cluster.
NeverBlink describes the responsibility we're taking on now.
The name stands for continuous attention to the databases that applications, businesses, and customers depend on also for operations done by agents in the blink of an eye. The platform doesn't wait for someone to open a dashboard before it starts looking for risk, waste, or degradation. And when a situation calls for human judgment, experienced engineers are there alongside the always-on technology.
This doesn't mean databases will never fail. Anyone who has operated production systems knows better than to make that promise. It means problems should never go unwatched or unexplained, and they shouldn't be left to grow into tomorrow's incident.
Pulse described a signal. NeverBlink describes our commitment.
This Is the Start of the Journey
A new name doesn't complete this transformation. It simply makes our direction explicit.
We'll continue adding databases that NeverBlink understands and deepening its intelligence around queries, workloads, cost, and reliability. We'll make that intelligence more useful to the AI agents becoming part of engineering and operational workflows. We'll automate more of the repetitive investigative work that consumes engineering time, while providing the controls and explanations teams need before they can trust that automation. And we'll keep turning hard-earned database expertise into a system more teams can use, whether or not they have a specialist for every engine they run.
The goal goes beyond better monitoring. We want a new model for database maintenance—continuous, intelligent, proactive, and available to every engineering team.
For existing customers, the team, product, and commitment you know are all staying in place. Our Elasticsearch and OpenSearch work continues, now as the foundation of a much broader mission.
We started by helping teams take the pulse of their search clusters.
Now we are setting out to reshape how databases everywhere are maintained. Expect new announcements almost every weeek as we start releasing what we've been building.
Welcome to NeverBlink.
