We asked a room of CTOs to pick apart our positioning. Here's what changed.

Recently, we posted in a CTO community, asking people who actually run infrastructure and platform teams for honest feedback on seiri.app. Not “would you use it” — we’ve heard enough of that from friendly audiences. The question was narrower: when you hear “cron and webhook monitoring,” what does that actually mean to you, and does it sound like a real problem or a solution looking for one?

We got back exactly the kind of feedback we asked for, from people running platform and infrastructure teams. Some of it stung a little. All of it was useful. This post is what we heard and what we did about it — including the parts we haven’t fixed yet.

“Too niche” was the first reaction

More than one reply led with some version of “cron and webhook monitoring sounds too niche to be a standalone product.” That’s a fair first impression, and niche isn’t automatically a problem in SaaS — but it pointed at something real: we were describing the mechanism (cron, webhooks, heartbeats) before we were describing the pain. Engineering leaders don’t need the concept of a heartbeat check explained to them. They need to know what breaks if they don’t have one.

What we changed: the homepage headline used to lead with a list of mechanisms — cron, heartbeat, dead man’s switch, Kubernetes. It now leads with the actual failure: “Silent failures cost you before anyone notices.” The mechanism is still there, one sentence later, but it’s no longer the first thing you read.

“Cron” quietly excluded an entire segment

One reply pointed out that every code example on the site was Linux cron syntax — 0 2 * * * ... — with zero mention of Windows Scheduled Tasks. If your shop runs on Windows, the entire site reads like it isn’t for you, even though the underlying idea (ping a URL when a scheduled thing finishes) doesn’t care what scheduled it.

What we changed: the homepage integration examples now include a Windows Task Scheduler / PowerShell tab alongside cron and email heartbeats. The hero copy and FAQ now say “cron jobs, Windows scheduled tasks, background workers, and Kubernetes CronJobs” instead of just cron. It’s a small copy change, but it was a real, previously unexamined gap — not a hypothetical one.

Two different conversations, wearing one pitch

This was the sharpest piece of feedback. Someone pointed out we were trying to have one conversation with two very different audiences:

• Engineering leadership (EM, VPE, CTO) hears “cron and webhook monitoring” and asks “doesn’t my observability stack already cover this?” That’s an education problem — they don’t yet believe the gap exists.
• The practitioner who’s actually on call already knows the gap exists. They’ve probably got a cron job pinging a healthchecks.io URL, or something homegrown. That’s a displacement problem — they need a reason to switch, not a reason to believe.

We were running both conversations through the same page copy, which meant we were half-explaining and half-selling to everyone.

What we changed: the “Who it’s for” section on the homepage now explicitly splits these two tracks instead of only listing job titles. Leadership gets a direct answer to “doesn’t my stack cover this,” with a link to a longer explanation. Practitioners get pointed straight at honest comparisons against the tools they’ve probably already looked at.

We also expanded the FAQ to actually answer the leadership question instead of dodging it: why doesn’t Datadog, Grafana, or CloudWatch already catch this? Short version — a job that exits 0 having done nothing doesn’t look wrong to any of those tools. They watch for infrastructure symptoms; we watch for the absence of the job itself. Most teams run both, not one instead of the other.

The clearest sentence on the site was buried in an FAQ

After we’d already made the changes above, one reply came back pointing at a single sentence, from our own FAQ:

“No. Seiri doesn’t poll a URL to see if your website is up. It’s built for scheduled work — cron jobs, background workers, and Kubernetes CronJobs — that ping Seiri when they finish. If the ping doesn’t arrive on schedule, you’re alerted immediately.”

Their read: that one sentence tells a manager or leader everything they need — what category this is, what it isn’t, and what it complements or competes with. And it was sitting in an FAQ accordion near the bottom of the page, instead of being the first thing anyone read.

That’s about as concrete and low-effort a fix as feedback gets, so it went straight to the top. The homepage subhead — the line directly under the headline — now says almost exactly that:

“Seiri doesn’t poll a URL to check if your site is up — it’s built for scheduled work instead. Your cron job, Windows scheduled task, worker, or Kubernetes CronJob pings Seiri when it finishes; if that ping doesn’t arrive on schedule, you’re alerted immediately.”

The FAQ answer is still there for anyone searching that exact question, but it’s no longer the only place this gets said.

Existing users aren’t a neutral read, and that’s worth remembering

One more piece of feedback wasn’t about the site copy at all — it was about how we gather feedback in the first place. The suggestion: ask existing users how they describe the problem Seiri solves for them, since practitioners are sometimes better at naming their own pain than a product-marketing pass ever will be.

We do this. But it’s worth saying out loud why it isn’t sufficient on its own: our existing users co-shaped this product with us over two years. They’ve absorbed our language back at us as much as we’ve absorbed theirs — they’re a useful source, but not a naive one. Real quotes pulled from onboarding calls and support threads are worth more than us guessing from memory, and we’re doing more of that. But we still need cold reactions from people who’ve never talked to us, like the ones that produced this whole post, because that’s the only way to catch the blind spots our own users have stopped noticing.

The feature-depth question — still open

The toughest note, and the one we haven’t resolved: detection plus notification is the whole product today. No root-cause layer, no trend analysis, no “here’s why this keeps happening.” One reply argued this is the actual reason the category reads as too niche to stand alone — not the naming.

We think that’s largely right, and we’re not going to pretend otherwise. Anomaly detection (flagging a job that still checks in, but has drifted much later than it used to) is on our roadmap as something we’re actively scoping — deliberately not shipped yet, because a noisy version of that feature would be worse than not having it. We’d rather say “not built yet” than dress up detection-only as something deeper than it is.

The pricing/ICP question — also still open

One reply made the case that the real buyer for this category is enterprise infrastructure — thousands of jobs, real financial risk from a silent failure. Our pricing tops out at 250 monitors and 15 seats, which is shaped for SMB and mid-market teams, not that buyer. That’s a genuine tension we haven’t resolved: either we build toward a larger-scale tier, or we consciously commit to the ICP our pricing already implies and stop hinting at “enterprise” language we don’t back up. We’re not going to paper over that with a copy fix — it’s a product and business decision, and we’d rather leave the question visibly open than quietly pretend it’s answered.

Why we’re posting this instead of just quietly editing the site

We build from a decade-plus of personal pain with exactly this failure mode, not from a market-research deck — and that shows up as blind spots like the ones above. The fastest way we know to find them is to ask people who’d actually be annoyed by a bad answer, and then show our work when they give us one.

If you run infrastructure or platform teams and have a reaction to any of the above — including “you still haven’t fixed X” — we’d rather hear it now. hello@seiri.app reaches the people who build this, and we read everything.