DEV Community: Mike Tickstem

Vercel cron alternative: what to use when built-in cron isn't enough

Mike Tickstem — Wed, 03 Jun 2026 12:39:28 +0000

Vercel's built-in cron triggers your serverless functions on a schedule. For simple use cases it works. But it has no failure alerts, no execution history on the Hobby plan, and no way to know whether your function actually completed successfully — only that it was called.

Where Vercel cron falls short

Vercel cron works by invoking one of your API routes on a schedule defined in vercel.json. The invocation is fire-and-forget — if your function times out, throws an error, or returns a non-2xx status, you get no alert. You find out when a user reports something is broken.

The specific gaps developers run into:

No failure alerts. Vercel does not send an email or webhook if your scheduled function fails.
No execution history on Hobby. The free plan does not retain cron execution history.
Timeout ceiling. Functions are subject to the same timeout limits as all serverless functions — 10 seconds on Hobby, up to 300 seconds on Pro.
HTTP-only. Vercel cron calls an HTTP endpoint on your app. You cannot schedule arbitrary background work outside your deployment.
No heartbeat monitoring. Even if your function is called successfully, you have no built-in way to verify it completed its work — only that it was invoked.
Minimum 1-hour interval on Hobby. Sub-hourly schedules require a paid plan.

If you are hitting any of these limitations, you need an external tool.

Comparison at a glance

Tool	Schedules jobs	Failure alerts	Heartbeat	Uptime monitoring	Free tier
Vercel built-in	✓	✗	✗	✗	✓ (1h min)
Tickstem	✓	✓	✓	✓	✓
Upstash QStash	✓	✓ (retries)	✗	✗	✓
Inngest	✓	✓	✗	✗	✓
cron-job.org	✓	✓ (basic)	✗	✗	✓

Tickstem — cron + heartbeat + uptime in one API key

Best for: developers who need scheduling, failure alerts, heartbeat monitoring, and uptime checks without managing multiple tools.

Tickstem is an external HTTP cron scheduler with built-in monitoring. You register your Vercel endpoint as a cron job, and Tickstem calls it on your schedule — every minute if needed, regardless of your Vercel plan. You get email alerts when a job fails or times out, full execution history, and response assertions to verify your endpoint returned the right status code.

Where it goes further than a simple cron service: Tickstem includes heartbeat monitoring. Your function pings a unique token URL at the end of each successful run. If the ping stops arriving within the expected window, you get alerted — catching cases where the function was called but silently failed partway through.

# Register your Vercel endpoint as a cron job
curl -X POST https://api.tickstem.dev/v1/jobs \
  -H "Authorization: Bearer $TICKSTEM_API_KEY" \
  -d '{
    "name": "nightly-sync",
    "schedule": "0 2 * * *",
    "endpoint": "https://your-app.vercel.app/api/nightly-sync"
  }'

Free tier: 1,000 executions, 5 uptime monitors, 5 heartbeat monitors per month.

Upstash QStash — reliable delivery with retries

Best for: developers already using Upstash who want guaranteed delivery with automatic retries.

QStash is a message queue and scheduler designed for serverless environments. You publish a message with a delay or schedule, and QStash delivers it to your endpoint with automatic retries on failure. It integrates naturally with the Vercel ecosystem.

It does not cover heartbeat monitoring or uptime checks — it is a scheduling and delivery layer, not a monitoring layer. Good choice if retry semantics matter more than observability.

Inngest — complex multi-step background jobs

Best for: multi-step workflows with fan-out, conditional logic, and event-driven triggers.

Inngest lets you define background functions in code and trigger them on a schedule or in response to events. It handles retries, concurrency, and step functions — things that are difficult to build reliably in a stateless serverless environment. First-class Vercel and Next.js integration.

The tradeoff is complexity. Inngest requires adding their SDK and restructuring your background work as Inngest functions. For simple "call this endpoint on a schedule and alert me if it fails," it is more than you need.

cron-job.org — simple external cron, free

Best for: plugging the scheduling gap with zero added complexity.

cron-job.org is a free external cron service that calls your URL on a schedule. Basic email alerts on failure, execution history retained. No SDK, no heartbeat monitoring, no uptime checks.

For developers who just need the scheduling gap filled without adding any infrastructure complexity, it is the lowest-friction option.

How to choose

Just need sub-hourly scheduling and basic failure alerts: cron-job.org covers the basics for free.
Need scheduling + know when the job actually completed its work: Tickstem — heartbeat monitoring is the missing piece Vercel does not provide.
Need reliable delivery with retries and already use Upstash: QStash fits naturally into that stack.
Building complex multi-step background workflows: Inngest is built for that use case.
Need cron + heartbeat + uptime without managing three tools: Tickstem bundles all three under one API key.

The pattern worth avoiding: starting with Vercel's built-in cron, adding cron-job.org for alerts, and eventually needing heartbeat monitoring — ending up with three separate tools and three places to check when something breaks.

Originally published at tickstem.dev. Also worth reading: Why cron jobs fail silently on serverless platforms.

Heartbeat monitoring for AI agent pipelines

Mike Tickstem — Tue, 26 May 2026 12:59:58 +0000

You deploy an AI agent to run nightly. It summarises data, writes a report, sends a Slack message. You set up uptime monitoring on the endpoint. The monitor stays green. Three days later you notice the Slack messages stopped. The agent hasn't run since Tuesday — and nothing alerted you.

This is the failure mode heartbeat monitoring is designed to catch. Here's how it works and why it's particularly important for AI agent pipelines.

The dead man's switch pattern

A dead man's switch alerts when something stops happening. Traditional monitoring alerts when something starts happening — a server goes down, an error rate spikes, a response time increases.

For AI agents, the dangerous failure is silence. The agent stops running. No error is thrown. No endpoint goes down. The work just quietly ceases. A dead man's switch catches this by expecting a regular signal — if the signal stops, something is wrong.

The implementation is straightforward: at the end of every successful agent run, after the real work is done, send a ping to a heartbeat URL. If the ping stops arriving within the expected window, you get an alert.

Why AI agents need this more than traditional jobs

Traditional cron jobs fail loudly — a non-zero exit code, an exception in the logs, a failed database write. You usually know something went wrong.

AI agents fail quietly. The model might hit a rate limit and return a graceful fallback response. A tool call might silently fail and the agent continues without it. The task might complete but produce empty or corrupted output — and your application code never raises an error because it got a valid HTTP response.

In all these cases, the endpoint is up, the job "ran," and traditional monitoring sees nothing. The heartbeat sees everything — because the agent itself decides whether to send the ping, and it only pings on genuine success.

Wiring it up

Create the heartbeat once and save the token:

curl -X POST https://api.tickstem.dev/v1/heartbeats \
  -H "Authorization: Bearer $TICKSTEM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name": "nightly-summary-agent", "interval_secs": 86400, "grace_secs": 3600}'
# → {"token": "your-64-char-token", ...}

Then in your agent's task handler, ping only after all the real work is verified complete:

async function runNightlySummaryAgent() {
  const summary = await generateSummary()

  if (!summary || summary.length < 100) {
    throw new Error("summary generation failed or returned empty output")
  }

  await postToSlack(summary)
  await writeToDatabase(summary)

  // only ping after everything succeeded
  await fetch(`https://api.tickstem.dev/v1/heartbeats/${HEARTBEAT_TOKEN}/ping`, {
    method: "POST"
  }).catch(err => console.error("heartbeat ping failed:", err)) // non-fatal
}

The ping is fire-and-forget — a network error on the ping should never block your agent from returning.

Setting the right interval and grace window

The interval is how often you expect the agent to run. The grace window absorbs variance.

A practical starting point:

Hourly agents: interval 3600s, grace 600s
Daily agents: interval 86400s, grace 3600s
Weekly agents: interval 604800s, grace 7200s

After a week of runs, check your actual execution durations and tighten the grace window to 2-3x your p95 runtime.

Multi-step pipelines

For agents that run a pipeline — fetch data, process it, write results, notify downstream — consider a heartbeat per stage if any stage can fail silently. One heartbeat at the end of the full pipeline tells you the pipeline completed. Individual stage heartbeats tell you exactly where it stopped.

A useful rule: the heartbeat ping should only fire after your agent has verified its own output — database write succeeded, Slack message delivered, output passes a sanity check. Not before.

Pausing during deployments

Deployments are the most common source of false heartbeat alerts. Pause before deploying:

# before deploy
curl -s -X POST https://api.tickstem.dev/v1/heartbeats/$HEARTBEAT_ID/pause \
  -H "Authorization: Bearer $TICKSTEM_API_KEY"

# after deploy completes
curl -s -X POST https://api.tickstem.dev/v1/heartbeats/$HEARTBEAT_ID/resume \
  -H "Authorization: Bearer $TICKSTEM_API_KEY"

Via MCP

If you're using Claude Code or another MCP-compatible client, the Tickstem MCP server exposes create_heartbeat and ping_heartbeat as native tools. The agent can set up its own dead man's switch during the initial scaffolding step.

Tickstem provides heartbeat monitoring, uptime checks, cron scheduling, and email verification under one API key. Free tier at app.tickstem.dev — no credit card required.

Monitoring AI agents in production

Mike Tickstem — Tue, 26 May 2026 12:58:00 +0000

Traditional monitoring asks one question: is the server up? If the endpoint returns 200, everything is fine. AI agents break that assumption. The server can be perfectly healthy while the agent silently produces wrong outputs, skips steps, runs over budget, or stops working entirely — all without triggering a single alert.

Monitoring autonomous agents requires a different mental model. Here's what actually breaks and how to catch it.

What traditional monitoring misses

Uptime monitoring tells you the endpoint responded. It says nothing about what the agent did inside that response. An agent endpoint that returns {"status": "ok"} in 50ms might have skipped the entire task due to a context length limit, a rate limit on the model API, or a malformed tool call that silently failed.

The failure modes specific to AI agents in production:

Silent tool failures. A tool call returns an error that the model handles by continuing without it. The task "completes" but with missing data.
Context window exhaustion. Long-running agents hit token limits mid-task and truncate their work. The HTTP response is still 200.
Model API degradation. The underlying model API is slow or returning degraded outputs. Your endpoint is up; the work is wrong.
Drift over time. An agent that worked last week starts producing subtly different outputs as the model is updated. No alert fires — outputs just quietly change.
Scheduled run skips. The agent was supposed to run at 06:00. It didn't. Nothing in your existing monitoring catches this because the server never went down.

The three layers of agent monitoring

Layer 1: Uptime monitoring

Still necessary — just not sufficient. Your agent's HTTP endpoint should be monitored for availability and response time. A degraded model API often manifests first as increased latency before it causes failures.

Set up an uptime monitor on the endpoint your agent exposes. A 30-second check interval catches most outages before users do. Configure timeout alerts — if your agent normally responds in under 10 seconds and starts taking 90, something is wrong even if it's still returning 200.

curl -X POST https://api.tickstem.dev/v1/monitors \
  -H "Authorization: Bearer $TICKSTEM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name": "summary-agent-endpoint", "url": "https://your-app.com/agents/summary/health", "interval_secs": 30, "timeout_secs": 15}'

Layer 2: Heartbeat monitoring

Uptime tells you the server is alive. Heartbeat tells you the agent actually did the work.

A heartbeat monitor works as a dead man's switch: your agent sends a ping after each successful completion. If the ping stops arriving within the expected window, you get an alert. The server being up is irrelevant — if the work stopped happening, the heartbeat catches it.

# Create a heartbeat — save the token
curl -X POST https://api.tickstem.dev/v1/heartbeats \
  -H "Authorization: Bearer $TICKSTEM_API_KEY" \
  -d '{"name":"daily-summary-agent","interval_secs":86400,"grace_secs":3600}'

# At the end of every successful agent run
curl -s -X POST https://api.tickstem.dev/v1/heartbeats/$HEARTBEAT_TOKEN/ping

The ping only fires on success — after the agent has verified its own output. Silence means failure, regardless of what the HTTP response said.

Layer 3: Execution history

The most underused layer. Every scheduled agent run should produce a logged record: when it ran, how long it took, whether it succeeded, and what it returned.

Without this, debugging a failure means reconstructing what happened from scattered logs. With it, you open the execution history and see immediately: the run at 06:03 took 4 minutes instead of the usual 45 seconds, returned a 500, and the response body contains a rate limit error from the model API.

If you're using HTTP-based scheduling for your agent, execution history comes for free — every run is logged with the full request and response.

A practical rule: any agent task that runs on a schedule and produces output that other systems depend on needs all three layers. Uptime alone is not monitoring — it's a pulse check.

Wiring it up via MCP

If you're building with Claude Code or a similar MCP-compatible agent, you can set up the full monitoring stack from within your editor. The Tickstem MCP server exposes create_monitor, create_heartbeat, and list_executions as native tools.

What good agent monitoring looks like

The goal is to answer three questions at any point in time, without digging through logs:

Is the agent endpoint reachable and responding normally? (uptime)
Did the agent complete its last scheduled task? (heartbeat)
What happened on the last N runs? (execution history)

When all three are in place, debugging shifts from "something might be wrong, let me check everything" to "here's exactly what happened and when."

Tickstem provides uptime monitoring, heartbeat checks, cron scheduling, and email verification under one API key. Free tier at app.tickstem.dev — no credit card required.

Scheduling recurring tasks in AI agent workflows

Mike Tickstem — Tue, 26 May 2026 12:47:17 +0000

When you build an AI agent that does something useful — summarises documents, monitors a feed, sends a report, syncs data — you eventually hit the same question: how do I make it run on a schedule? Not once, triggered manually. On a schedule, reliably, while I'm not watching.

The answer sounds obvious: cron job. But cron jobs for AI agents have a specific set of failure modes that traditional scheduled tasks don't. This post walks through the problem and how to solve it cleanly.

Why AI agent scheduling is different

A traditional cron job runs a deterministic script. It succeeds or it fails. You can usually tell which from the exit code or the output.

An AI agent run is different in three ways:

Variable duration. The same agent task might take 8 seconds or 4 minutes depending on the model, the input, and whether any tools needed retries. A fixed timeout either kills legitimate runs or hides runaway ones.
Partial success. The agent might complete three out of four steps before failing silently on the fourth. The job exits 0 but the work wasn't done.
Downstream dependencies. Other systems may be waiting on the agent's output. If the agent run is delayed or skipped, nothing downstream fires — and nothing alerts you.

These failure modes make it worth thinking carefully about how you schedule agents, not just whether you schedule them.

The scheduling options

There are three common approaches, each with different tradeoffs.

Option 1: Platform-native cron (Vercel, Railway, Render)

If your agent runs as a serverless function or a hosted service, the platform usually offers built-in cron scheduling. You configure a schedule, the platform sends an HTTP request to your endpoint at the right time.

This works until it doesn't. Platform cron has no execution history, no alerting on failure, and no guarantee of exactly-once delivery. If the platform retries the request — which it will, eventually — your agent runs twice. For idempotent tasks that's annoying. For tasks that send emails or process payments, it's a bug.

Option 2: A queue with a scheduler

A more robust approach: a dedicated scheduler posts a message to a queue at the scheduled time. A worker pulls from the queue and runs the agent. Whoever pulls the message first wins — the message is gone, so no second worker can pick it up.

This gives you exactly-once semantics via atomic queue operations. Redis BRPOP is the classic implementation: it blocks until a message arrives, then removes it and returns it to exactly one caller. Ten workers can be waiting — only one gets the job.

The tradeoff is operational overhead: you need a queue, a scheduler, and workers, all running and monitored. For a single agent this is usually overkill.

Option 3: HTTP-based scheduling with execution history

The approach that works well for most agent deployments: an external scheduler sends an HTTP POST to your agent's endpoint on the schedule you define. The scheduler logs every execution — request headers, response status, response body, duration, whether it ran on time.

When the run fails, you have the full record: what was sent, what came back, how long it took. When runs stop happening, you get an alert. This is what Tickstem provides.

curl -X POST https://api.tickstem.dev/v1/jobs \
  -H "Authorization: Bearer $TICKSTEM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name": "daily-summary-agent", "url": "https://your-app.com/agents/daily-summary", "schedule": "0 8 * * *", "timeout_secs": 300}'

The scheduler fires a POST to your endpoint at 08:00 every day. Your endpoint runs the agent and returns when it's done. The execution — status code, response body, duration — is recorded and available in the dashboard or via API.

Wiring it up with the MCP server

If you're building with Claude Code or another MCP-compatible agent, Tickstem exposes its scheduling tools natively via MCP. The agent can register its own cron jobs without leaving the editor:

{
  "mcpServers": {
    "tickstem": {
      "command": "tsk-mcp",
      "env": { "TICKSTEM_API_KEY": "your-key" }
    }
  }
}

With the MCP server running, the agent can call create_job, list_jobs, and get_executions as native tools. No context switching, no separate dashboard visit to wire up the schedule.

The MCP integration means the agent can also inspect its own execution history. If a previous run failed, the agent sees that on the next invocation and can adjust — retry a step, notify a human, or log a more specific error.

Handling variable agent duration

Set timeout_secs generously. For an agent that usually takes 30 seconds but occasionally takes 3 minutes on heavy inputs, a 60-second timeout generates false failures. Start at 5-10x your typical duration, then tighten once you have execution history data to work from.

Tickstem records the actual duration of every run. After a week of executions, you'll have a realistic p99 — use that as your timeout baseline.

Pairing scheduling with heartbeat monitoring

Scheduling tells you when the agent starts. It doesn't tell you whether the agent actually completed the work it was supposed to do.

For that, add a heartbeat ping at the end of the agent's task — after all the real work is finished, not before. If the ping stops arriving, something went wrong inside the run even though the HTTP response was 200.

# At the end of your agent's task handler
curl -s -X POST https://api.tickstem.dev/v1/heartbeats/$HEARTBEAT_TOKEN/ping

Scheduling + heartbeat together give you the full picture: the scheduler confirms the agent was invoked on time, the heartbeat confirms it did what it was supposed to do. See heartbeat monitoring for background jobs for the full pattern.

A note on exactly-once for agents

Most agent tasks are not naturally idempotent. Sending a summary email twice, creating a duplicate report, or processing the same input twice are real problems. If you're using platform-native cron, add an idempotency check in your endpoint — a database flag, a Redis key, or a content hash — before the agent does anything irreversible.

If you're using Tickstem's scheduler, the queue-backed execution model handles this at the infrastructure level. One schedule tick, one message, one execution.

Tickstem provides HTTP-based cron scheduling, uptime monitoring, heartbeat monitoring, and email verification under one API key. Free tier at app.tickstem.dev — no credit card required.

How to detect and block temporary email addresses at signup

Mike Tickstem — Thu, 21 May 2026 16:43:22 +0000

Temp mail services give anyone a working inbox with no registration. They pass every syntax check, often pass MX validation, and vanish within hours. Here's how to reliably detect and block them before they reach your database.

What are temporary email addresses?

Temporary email — also called disposable email, throwaway email, or temp mail — is a short-lived inbox provided by services like Temp-Mail.org, Guerrilla Mail, 10 Minute Mail, Mailinator, and hundreds of others. The user gets a working address instantly, no registration required. Emails arrive in real time. The inbox expires anywhere from 10 minutes to a few days.

From a purely technical standpoint, these addresses are valid. The domain has MX records. The inbox receives email. A regex check passes. A basic MX lookup passes. The address looks identical to a legitimate one.

Why temp mail hurts your product

Developers often underestimate the problem until they look at their user table. Common patterns:

Free tier abuse. A single person creates dozens of accounts to get repeated access to a free trial or free quota.
Skewed analytics. Signup numbers look healthy but most accounts are one-time throwaways that never convert.
Dead email lists. Marketing emails bounce at a high rate once the temp addresses expire, damaging your sender reputation.
Fraud and spam. Bad actors use disposable addresses to post spam, file fake support tickets, or exploit referral bonuses.
Wasted onboarding cost. Every automated welcome email, verification email, and drip sequence fired at a dead address costs money and deliverability reputation.

The challenge: temp mail evolves faster than blocklists

The naive solution is a domain blocklist — a text file of known disposable providers. That list exists. You can find it on GitHub with 100,000+ domains. The problem is the list is always stale. New temp mail services appear daily, and existing ones cycle through domains to evade filters.

A purely blocklist-based approach catches the obvious cases (mailinator.com, guerrillamail.com) but misses the long tail. The detection problem is fundamentally an ongoing one, not a one-time list import.

How to detect temporary email addresses

1. MX record checks

Most temp mail providers share infrastructure. Certain mail servers handle thousands of disposable domains. Checking whether a domain's MX record points to a known temporary mail provider's servers catches a large slice of the problem, including domains that don't appear on any blocklist yet.

# DNS lookup for MX records
dig MX tempinbox.com
# → points to a shared disposable mail server

The limitation: large providers like Gmail and Outlook also run shared infrastructure, so you can't block on shared servers alone. You need to combine MX analysis with domain reputation data.

2. Domain blocklist lookup

A curated blocklist handles the well-known providers reliably. The key is using a maintained list, not a static file you imported once. Providers like Tickstem update the blocklist continuously, so you get coverage for new domains without any work on your end.

3. Domain age and registration signals

Temp mail domains are often newly registered or have minimal web presence. WHOIS data and domain age can supplement other signals. A domain registered two days ago with an MX record pointing to shared mail infrastructure is almost certainly disposable.

4. Pattern matching on common structures

Many temp mail services use predictable address formats: random@domain.com where the local part is a UUID or random string, or a username that looks machine-generated. Pattern matching alone has too many false positives to be reliable, but it adds signal when combined with other checks.

5. API-based verification (the reliable approach)

All of the above signals need to be combined and weighted. The practical approach is to use a purpose-built verification API that handles the signal aggregation, keeps blocklists current, and returns a single verdict per email address.

Here's what a one-call check looks like with Tickstem:

curl -X POST https://api.tickstem.dev/v1/verify \
  -H "Authorization: Bearer tsk_your_key" \
  -H "Content-Type: application/json" \
  -d '{"email": "user@tempinbox.com"}'

{
  "email": "user@tempinbox.com",
  "valid": false,
  "disposable": true,
  "mx": true,
  "reason": "disposable_domain"
}

The disposable field is the one to act on. Block or flag any address where it returns true.

Implementation patterns

Block at the point of entry

The right place to check is on your signup form, before writing anything to your database. Call the verification API on form submission. If disposable: true, return an error to the user immediately:

import { VerifyClient } from '@tickstem/verify';

const verify = new VerifyClient({ apiKey: process.env.TICKSTEM_API_KEY });

async function handleSignup(email) {
  const result = await verify.check(email);

  if (result.disposable) {
    throw new Error('Please use a permanent email address to sign up.');
  }

  if (!result.valid) {
    throw new Error('That email address does not appear to be valid.');
  }

  // proceed with signup
}

Soft-block vs hard-block

For most products, a hard block (reject the signup entirely) is the right default. Some products prefer a soft block: allow signup but flag the account for manual review, restrict access to paid features, or require additional verification before granting full access.

The choice depends on your tolerance for friction. Hard blocks eliminate the problem entirely; soft blocks let you study edge cases before committing to a policy.

Don't check on every request

Email verification is a signup-time check, not a per-request check. Cache results by domain if you're processing bulk imports. For real-time signup forms, one check per submission is the right pattern.

Popular temp mail services your users are using

Service	Notes
Temp-Mail.org	Very popular, cycles through many domains
Guerrilla Mail	Long-running, multiple domains
10 Minute Mail	Fixed 10-minute expiry
Mailinator	Public inboxes at mailinator.com and aliases
Throwam	Newer, used to evade basic blocklists
Dispostable	API-accessible disposable inboxes
Yopmail	Persistent but anonymous inboxes

The list above is illustrative, not exhaustive. There are thousands of active disposable providers. Maintaining your own blocklist is a full-time job — this is why API-based verification is the practical choice for most teams.

What about legitimate use cases?

Privacy-conscious users sometimes use alias services — Apple's Hide My Email, SimpleLogin, or Fastmail aliases — to protect their real address. These are different from temp mail: the address is permanent, forwards to a real inbox, and the user intends to receive ongoing emails.

A good verification API distinguishes between disposable temp mail and privacy aliases. Tickstem's disposable flag is false for forwarding aliases because they exhibit the behavior of real, permanent addresses (active MX, established domain, no expiry).

Summary

Blocking temp mail reliably requires combining multiple signals: domain blocklists, MX record analysis, domain reputation, and pattern matching. Doing this yourself means maintaining a continuously updated dataset. A verification API handles that maintenance and gives you a single field to act on.

The check takes one API call at signup time. The cost of not checking is fake accounts, abused free tiers, and degraded sender reputation — costs that compound over time.

Block temp mail in one API call: tickstem.dev — 500 checks free per month, no credit card required.

Add production monitoring to Claude Code apps in minutes

Mike Tickstem — Thu, 21 May 2026 16:43:06 +0000

AI coding agents are getting good at writing application code. The gap is the operational layer — the cron jobs, health checks, and monitoring that keep a production app running. Tickstem's MCP server closes that gap by letting Claude Code provision infrastructure directly, without you switching context to another dashboard.

The problem with AI-built apps in production

You build a feature with Claude Code in an afternoon. The code is clean, the tests pass, it deploys. Then the background job that sends daily digests silently stops running. Nobody notices for three days because there is no monitoring. The job was scaffolded by the agent, but the operational layer — the heartbeat check, the cron schedule, the alert on failure — was never set up.

This is the gap. AI agents are excellent at writing application logic. They are bad at the surrounding infrastructure, not because they lack the ability, but because the tools for provisioning that infrastructure are not natively available to them. They can generate curl commands and tell you what to run — but they cannot actually register the monitor.

Tickstem's MCP server changes this. Once it is configured, Claude Code can register cron jobs, create uptime monitors, set up heartbeat checks, and verify email addresses as part of the normal development workflow.

Installing the Tickstem MCP server

First, get a Tickstem API key from app.tickstem.dev/dashboard/keys. The free tier is enough to follow this walkthrough.

Download the tsk-mcp binary for your platform from github.com/tickstem/mcp/releases and place it somewhere on your PATH. Then add Tickstem to your Claude Code MCP configuration:

# Add to your Claude Code project via CLI
claude mcp add tickstem tsk-mcp --env TICKSTEM_API_KEY=tsk_your_key_here

Or add it manually to .claude/settings.json in your project:

{
  "mcpServers": {
    "tickstem": {
      "command": "tsk-mcp",
      "env": {
        "TICKSTEM_API_KEY": "tsk_your_key_here"
      }
    }
  }
}

Restart Claude Code. When the MCP server connects successfully, Claude has access to Tickstem's tools and can use them without any further instructions.

Registering a cron job

Suppose you have just built a daily digest endpoint at /api/cron/digest. Instead of manually logging into a dashboard to schedule it, you ask Claude directly:

You: Register a cron job that hits POST /api/cron/digest on my production app every day at 9am UTC, Monday through Friday.

Claude Code:

I'll register that with Tickstem now.

✓ Created cron job daily-digest

Schedule: 0 9 * * 1-5

Endpoint: https://yourapp.com/api/cron/digest

Method: POST

The job is active. You'll receive an email alert if it fails. You can view execution history at app.tickstem.dev/dashboard/jobs.

The job is now registered and running. No dashboard visit, no copy-pasting a webhook URL, no configuring retry logic — that is all handled by Tickstem's scheduler.

Setting up a heartbeat monitor

A cron job tells Tickstem when to run your endpoint. A heartbeat monitor is the reverse: your job tells Tickstem it ran successfully. If the ping stops arriving, you get an alert. This catches a different failure mode — the scheduler fires but the job itself crashes or times out silently.

You: Add a heartbeat monitor for the digest job. It should alert me if no ping arrives within 25 hours — that gives a 1-hour buffer on the daily schedule.

Claude Code:

Created heartbeat monitor daily-digest-heartbeat

Interval: 86400s (24h)

Grace: 3600s (1h)

Ping URL: https://api.tickstem.dev/v1/heartbeats/a3f8...c2d1/ping

I'll add the ping call to your digest handler. At the end of a successful run, your job should POST to that URL — no auth header needed, the token in the URL is the credential.

Claude then updates your handler to include the ping:

import httpx

async def send_digest():
    # ... your existing digest logic ...

    # Ping Tickstem at the end of a successful run
    # Non-fatal — don't let a monitoring outage block your job
    try:
        httpx.post(
            "https://api.tickstem.dev/v1/heartbeats/a3f8...c2d1/ping",
            timeout=5,
        )
    except Exception:
        pass  # log this, but don't raise

Two monitors for one job — the scheduler fires it, the heartbeat confirms it completed. If either fails, you know immediately.

Verifying email addresses at signup

Email verification is the same pattern. You are adding a signup form and want to reject disposable addresses before they reach your database:

You: Add email verification to the signup handler. Reject disposable and role-based addresses with a clear error message.

Claude Code:

I'll add Tickstem email verification to your signup handler. The free tier gives you 500 verifications per month — enough for early-stage signups.

from tickstem import VerifyClient
import os

verify = VerifyClient(os.environ["TICKSTEM_API_KEY"])

async def signup(email: str):
    result = verify.verify(email)

    if not result.valid:
        raise ValueError(f"Email address not accepted: {result.reason}")
    if result.disposable:
        raise ValueError("Disposable email addresses are not accepted.")
    if result.role_based:
        raise ValueError("Please use a personal email address.")

    # safe to store
    await db.users.insert(email=email)

What this looks like end to end

In a typical Claude Code session building a production feature, the full ops setup now takes one conversation:

Build the feature and deploy the endpoint
Ask Claude to register the cron schedule
Ask Claude to add a heartbeat monitor and update the handler
Ask Claude to add email verification to any signup flows

The agent provisions everything, writes the integration code, and confirms what was created. You end up with a production-ready feature — scheduler, monitoring, and validation — without touching a separate dashboard.

What Claude Code can do via MCP: register and manage cron jobs, verify email addresses, list existing jobs and their execution history.

What requires direct API calls (code Claude generates for you): heartbeat ping calls, uptime monitor creation, heartbeat monitor creation. Claude writes the integration code; you run it once to provision.

Why this matters beyond convenience

The practical benefit is obvious — fewer context switches, faster setup. But there is a structural argument too.

The operational layer of most applications is set up manually, inconsistently, and often incompletely. Developers know they should add a heartbeat monitor. They do not, because it means opening another tab, finding the dashboard, creating the resource, copying the URL, and updating the code. It takes twenty minutes and breaks flow.

When that setup is a two-sentence conversation with the agent already open in your editor, it gets done. Every time. The gap between "application code" and "production-ready application" closes because the tooling for both lives in the same place.

Get your API key and add Tickstem to Claude Code: app.tickstem.dev — free tier includes 1,000 cron executions, 5 heartbeats, 5 uptime monitors, and 500 email verifications per month.

Healthchecks.io alternatives for developers (2026)

Mike Tickstem — Wed, 20 May 2026 11:33:29 +0000

Healthchecks.io is a well-designed tool for one specific problem: alerting you when a scheduled job stops checking in. If that is all you need, it is hard to beat. But most developers eventually need more — cron scheduling, uptime monitoring for HTTP endpoints, or all three in one place. Here is a clear comparison of the best alternatives.

What Healthchecks.io does well

Healthchecks.io is a dead man's switch for cron jobs. Your job sends an HTTP ping to a unique URL after each successful run. If the ping stops arriving within the expected window, Healthchecks.io sends an alert. The concept is simple, the implementation is clean, and it is open source — you can self-host it for free.

The free hosted tier gives you 20 checks and three months of log history, which is enough for most small projects. Setup takes about five minutes. If you only need heartbeat monitoring and nothing else, it remains an excellent choice.

Why developers look for alternatives

The typical reason is scope. Healthchecks.io monitors whether your job runs — it does not schedule the job, and it does not monitor whether your HTTP endpoints are up. Once you add uptime monitoring for your API and a cron scheduler for your background tasks, you have three separate tools, three dashboards, and three invoices.

Other common reasons:

Self-hosting overhead. The open source version requires a server, a Postgres database, and ongoing maintenance. For solo developers this is often not worth the operational cost.
Pricing at scale. The hosted Business plan jumps significantly once you need more than 20 checks or additional team members.
No cron scheduling. Healthchecks.io tells you a job did not run — it does not run the job for you. Serverless environments like Vercel and Railway make this a common pain point.
No API-first workflow. Creating and managing checks programmatically is possible but limited compared to tools built around an API-first model.

Comparison at a glance

Pricing approximate — verify on each vendor's site before purchasing.

Tool	Heartbeats	Cron scheduling	Uptime monitoring	Free tier	Starting price
Healthchecks.io	✓	✗	✗	20 checks	~$20/mo
Tickstem	✓	✓	✓	5 heartbeats	$12/mo
Cronitor	✓	✓	✓	5 monitors	~$25/mo
Dead Man's Snitch	✓	✗	✗	1 snitch	~$9/mo
Better Uptime	✓	✗	✓	10 monitors	~$24/mo
Sentry Crons	✓	✓	✗	Yes (with Sentry)	Free

The alternatives in detail

Best for: developers who need cron + heartbeat + uptime under one key

Tickstem
Tickstem bundles cron job scheduling, heartbeat monitoring, and uptime monitoring under a single API key. The heartbeat implementation is identical in concept to Healthchecks.io — each heartbeat gets a unique token, your job pings the URL after each run, and you get an alert after two consecutive missed intervals.

The difference is what surrounds it. You can schedule the job from Tickstem directly, monitor the HTTP endpoint it hits, and receive all alerts in one place. There is a Go, Node.js, and Python SDK. The free tier includes 5 heartbeats, 5 uptime monitors, and 1,000 cron executions per month.

# Create a heartbeat
curl -X POST https://api.tickstem.dev/v1/heartbeats \
  -H "Authorization: Bearer $TICKSTEM_API_KEY" \
  -d '{"name":"nightly-export","interval_secs":86400,"grace_secs":3600}'

# Ping it from your job
HEARTBEAT_TOKEN="your-64-char-token"
curl -X POST https://api.tickstem.dev/v1/heartbeats/$HEARTBEAT_TOKEN/ping

Pros: cron + heartbeat + uptime in one tool, API-first, Go/Node/Python SDKs, lower entry price than Cronitor.

Cons: newer product, smaller community than established alternatives.

Best for: teams that want a polished all-in-one monitoring platform

Cronitor
Cronitor is the most direct feature-equivalent to the Tickstem bundle — it handles cron job monitoring, heartbeat monitoring, and uptime checks. It has been around longer and has a larger community. The dashboard is well-designed and the alerting is flexible.

The tradeoff is price: Cronitor's paid plans start higher, and features like Slack alerting and team seats are gated behind more expensive tiers. If you are a team with a monitoring budget, Cronitor is a mature choice. If you are a solo developer or early-stage product, the cost is harder to justify.

Pros: mature product, strong community, comprehensive alerting options.

Cons: higher pricing, some features require paid tiers that are expensive for small teams.

Best for: simple heartbeat monitoring with minimal setup

Dead Man's Snitch
Dead Man's Snitch is the closest conceptual equivalent to Healthchecks.io. It does one thing: alert you when a job stops checking in. The free tier gives you one snitch — enough to evaluate the product. Setup is extremely simple.

If you genuinely only need heartbeat monitoring and want the smallest possible tool, Dead Man's Snitch or Healthchecks.io are the right choices. Neither does cron scheduling or uptime monitoring.

Pros: dead simple, focused, low cost entry point.

Cons: heartbeat-only, no uptime monitoring, no cron scheduling.

Best for: teams that need uptime + heartbeat but not cron scheduling

Better Uptime
Better Uptime covers uptime monitoring and heartbeat checks in a clean interface with strong on-call and incident management features. If your primary concern is whether your API endpoints are responding and your background jobs are running — but you handle scheduling elsewhere — Better Uptime is a solid choice.

It does not schedule cron jobs. Pricing is competitive for small teams but scales quickly as you add more monitors and team members.

Pros: clean UI, good on-call features, uptime + heartbeat covered.

Cons: no cron scheduling, pricing escalates with team size.

Best for: teams already using Sentry

Sentry Crons
If your application already sends errors to Sentry, Sentry Crons is the easiest addition. It monitors whether your cron jobs run on schedule and surfaces missed or failed jobs alongside your error tracking. It is included in Sentry's free tier.

The limitation is scope — Sentry Crons does not monitor uptime for HTTP endpoints. It also ties you deeper into the Sentry ecosystem, which may or may not suit your stack. But if you are already paying for Sentry, adding cron and heartbeat monitoring costs nothing extra.

Pros: free if you already use Sentry, good cron + heartbeat coverage, integrated with error tracking.

Cons: no uptime monitoring, requires Sentry, limited alerting channels on free tier.

Self-hosted Healthchecks

Worth a separate mention: Healthchecks.io is fully open source and you can run it yourself. If you have a server already and want zero recurring cost for heartbeat monitoring, the self-hosted version is a legitimate option. The setup requires Docker or a Python environment, Postgres, and a mail server for alerts. For solo developers comfortable with server ops, this is hard to beat on cost.

The downside is ongoing maintenance. Every upgrade, database migration, and backup falls on you. For a monitoring tool — something you depend on to tell you when things break — operational overhead is worth factoring in.

How to choose

Just heartbeat monitoring, minimal cost: Healthchecks.io free tier or self-hosted. Dead Man's Snitch if you want simpler setup.

Heartbeat + uptime, no cron scheduling: Better Uptime.

Heartbeat + cron scheduling + uptime, one tool: Tickstem or Cronitor. Tickstem is cheaper for small teams; Cronitor is more mature for larger ones.

Already using Sentry: Add Sentry Crons first — it costs nothing extra and covers most cases.

The pattern that catches most developers is starting with Healthchecks.io for heartbeats, adding UptimeRobot for uptime, and eventually needing a cron scheduler — ending up with three separate tools. If you can see that combination in your future, starting with a bundle is worth the slightly higher entry cost.

Why email validation is harder than a regex

Mike Tickstem — Wed, 20 May 2026 10:28:54 +0000

The pattern /.+@.+\..+/ accepts admin@mailinator.com, test@defunct-domain.io, and notreal@typo.vom. Here's what actually needs to happen before you trust an email address.

Every sign-up form validates email addresses. Most do it with a regex. The regex catches obvious typos — missing @, no domain — but it lets through a much larger class of addresses that will never receive a message. Those addresses quietly inflate your list, skew your open rates, and cost you money on every send.

The four problems a regex can't catch

The domain doesn't exist. A user types alice@gmial.com. The regex passes. The domain has no mail server. Your welcome email bounces. Your sender reputation drops. The domain gmial.com used to be a common typo trap — attackers registered it to harvest credentials from misdirected password resets.
The domain is real but the inbox is disposable. Services like Mailinator, Guerrilla Mail, and a hundred others give anyone a working inbox with no sign-up. The email is valid — it will actually receive your message — but the address belongs to no one in particular. Anyone who knows the address can read it. Users create throwaway accounts to claim trial offers, avoid marketing, or test your app without commitment.
The address is role-based. info@company.com is a real inbox shared by a team. noreply@company.com likely discards everything. admin@company.com probably goes to an ops rotation. These aren't personal addresses — they're organizational ones. Sending transactional or marketing email to role inboxes leads to low engagement and higher unsubscribe rates because nobody "owns" the address.
The domain exists but the mailbox doesn't. SMTP probing — actually connecting to port 25 and issuing a RCPT TO command — can answer this question. But most mail servers are configured to accept any address at the gateway and bounce later (a technique called catch-all), specifically to defeat probing. And most cloud providers block outbound port 25 entirely, so your probe never even reaches the server.

What you can actually do

Given those constraints, a practical validation pipeline looks like this:

Parse the syntax — not just a regex, but a proper RFC 5322 parse. This catches malformed addresses and normalizes the format.
Look up MX records — a DNS query confirms the domain has at least one mail exchanger. This is fast (<100ms), cheap, and reliable. It rejects typos like gmial.com and abandoned domains.
Check against a disposable domain list — a maintained list of throwaway services. Mailinator, Guerrilla Mail, Trashmail, and several hundred others. This is a blocklist problem, not a detection one.
Flag role-based prefixes — a simple match against known generic prefixes: admin, info, noreply, support, billing, etc. Flag rather than block — some legitimate users do sign up with a shared inbox. Steps 1–3 give you a reliable answer. Step 4 gives you a signal. Together, they catch the vast majority of addresses that will cause you problems.

The code

The Tickstem verify SDK runs all four checks with one call:

import "github.com/tickstem/verify"

client := verify.New(os.Getenv("TICKSTEM_API_KEY"))

result, err := client.Verify(ctx, email)
if err != nil {
    // handle quota or network error
}

if !result.Valid {
    // result.Reason explains why: "invalid syntax", "no MX records found for domain",
    // or "disposable email domain"
    return fmt.Errorf("email not accepted: %s", result.Reason)
}

if result.RoleBased {
    // your call — warn the user, or log and proceed
}

The result is stored in your account history so you can audit it later. The API never probes the mail server — no port 25 calls, no contact with the recipient's infrastructure.

When to validate

At sign-up — block disposable and invalid addresses before they enter your system. A user who can't sign up with a throwaway address either provides a real one or leaves. Both outcomes are better than a list full of ghost accounts.

Before a bulk send — scrub your list against the API if it was collected through a form that didn't validate at the time. Sending to a high percentage of invalid addresses is the fastest way to get flagged by Gmail and Outlook's filtering algorithms.

At re-engagement — if an address hasn't opened anything in 90 days, re-verify before sending. MX records disappear. Domains get abandoned. What was valid a year ago may not be now.

On SMTP probing: Some services advertise mailbox-level verification via SMTP. In practice, catch-all servers make the result unreliable, port 25 is blocked on most cloud providers, and the latency (300ms–3s per check) makes it unsuitable for sign-up flows. MX + disposable + role-based covers most of what matters in production.

Try it

The verify API is available on all Tickstem plans. The Free tier includes 500 verifications per month.

Go: go get github.com/tickstem/verify.
Node.js: npm install @tickstem/verify.
Python: pip install tickstem.

How to detect and block Mailinator emails (and 4,000+ disposable domains)

Mike Tickstem — Wed, 20 May 2026 10:14:01 +0000

Mailinator gives anyone a working inbox at any @mailinator.com address with no signup, no password, no verification. For your application, that means free-tier abuse, fake signups, and a contact database full of addresses nobody owns. Here is what Mailinator actually is, why a blacklist alone is not enough, and how to block it reliably.

What is Mailinator?

Mailinator is a free, public disposable email service. Anyone can send mail to anything@mailinator.com and read it at mailinator.com without registering, logging in, or proving ownership. Inboxes are public — if you know the address, you can read the mail. Messages auto-delete after a few hours.

The service exists for a real reason. Developers use it to test signup flows, password resets, and transactional email without polluting personal inboxes. QA engineers use it to verify that delivery actually works. The problem is that the same property that makes it useful for testing — anyone can claim any address instantly — makes it the path of least resistance for anyone who wants to avoid giving you a real email.

Mailinator email lookup: how it works in practice

A user types j8djk2@mailinator.com into your signup form. They open https://www.mailinator.com/v4/public/inboxes.jsp?to=j8djk2 in another tab. Your welcome email arrives there. They click the verification link, claim the free trial, and walk away. The address you stored in your database is shared with anyone on the internet who guesses or learns it.

Mailinator also operates several alternative domains for users trying to get past simple blocklists: @maildrop.cc, @guerrillamail.com, @throwawaymail.com, @10minutemail.com, and dozens more. Mailinator itself sells a paid tier for legitimate enterprise testing with private inboxes — most of the public abuse comes from the free public side.

Mailinator disposable email risks for your application

The risks depend on what your application does, but they fall into three buckets:

1. Free trial and credit abuse
Every SaaS with a free trial faces this. A single person creates dozens of accounts using name1@mailinator.com, name2@mailinator.com, and so on. Each account claims the trial credits, free API calls, or starter quota. For a tool with a generous free tier and meaningful unit costs (AI inference, video processing, SMS), this drains real money. Stripe will not chargeback you because nobody charged anything — the damage is on the cost side.

2. Compromised email-verification security
If your "email verification" step just confirms that someone can receive a message at the address, Mailinator passes it trivially. Anyone who can guess the address can read the verification link. Any account using a Mailinator address has no real owner — there is no second factor, no recovery channel that only one person controls. Treating these accounts as "verified" gives a false sense of security.

3. Marketing list and deliverability damage
Mailinator inboxes auto-delete. Messages are read once or not at all. If your sender reputation depends on engagement metrics (Gmail, Outlook, Yahoo all weight this heavily), having a meaningful chunk of your list at @mailinator.com drags your domain reputation down. You can ship the best email campaign of your life and it will land in spam because your list has too many addresses nobody opens.

Why a regex check is not enough

The standard email regex like /^[^@]+@[^@]+\.[^@]+$/ happily accepts fake@mailinator.com, throwaway@guerrillamail.com, and burner@10minutemail.com. The address is syntactically valid. The domain exists. Messages actually deliver. There is nothing the regex can catch — disposable email isn't a malformed address, it's a perfectly valid address you don't want.

You need a different category of check entirely: looking up whether the domain itself belongs to a known disposable service.

Approach 1: Static blocklist

The simplest defence is a list of disposable domains. Maintained lists exist on GitHub:

disposable-email-domains/disposable-email-domains — about 4,000 domains, MIT licensed, updated monthly
martenson/disposable-email-domains — similar coverage, also community-maintained Drop the list into your signup handler and reject any domain in it:

// JavaScript example — works the same in any language
import disposableDomains from "./disposable-domains.json"

const isDisposable = (email) => {
  const domain = email.split("@")[1]?.toLowerCase()
  return disposableDomains.has(domain)
}

if (isDisposable(formData.email)) {
  return res.status(400).json({ error: "Please use a non-disposable email address" })
}

This blocks maybe 80 percent of the disposable traffic you will see. The reason it isn't 100 percent: disposable services launch new domains weekly. By the time your blocklist updates, the latest @catchmail.io or @spamgone.org has already been used to register hundreds of trial accounts. You are always slightly behind.

Approach 2: MX record lookup

Mailinator and most disposable services share a small set of MX records. A DNS query for the domain's mail exchangers reveals not just whether the domain receives mail (it does) but who runs that infrastructure.

$ dig +short MX mailinator.com
10 mail2.mailinator.com.
20 mail.mailinator.com.

$ dig +short MX guerrillamail.com
20 mx-guerrillamail.com.

Combine MX-resolution with a pattern check on the MX hostname. A domain whose MX points at mail.mailinator.com is clearly Mailinator regardless of what the apex domain is called. This catches white-label disposable services that share the same backend.

This is also where you catch the second-biggest signup problem: domains with no MX records at all. A typo like user@gmial.com passes regex but fails MX lookup. Rejecting these saves you from bounces and the sender-reputation hit they cause.

Approach 3: Full verification — MX, disposable, role-based, syntax

The robust signup check combines all four signals:

RFC-5322 syntax parse (not just a regex — catches subtle malformation)
MX record lookup (rejects typo domains and abandoned domains)
Disposable domain match (rejects Mailinator and ~4,000 others)
Role-based prefix detection (admin@, info@, noreply@ — flag but don't always block)

The Tickstem verify API does all four with a single call. Here is the Go SDK example:

import "github.com/tickstem/verify"

client := verify.New(os.Getenv("TICKSTEM_API_KEY"))

result, err := client.Verify(ctx, "j8djk2@mailinator.com")
if err != nil {
    log.Printf("verify failed: %v", err)
    return // fall back to accept-and-warn, never block on outage
}

if result.Disposable {
    return errors.New("please use a non-disposable email address")
}
if !result.MXFound {
    return errors.New("email domain does not appear to accept mail")
}
if result.RoleBased {
    log.Printf("signup with role-based address: %s", email)
    // proceed but flag for review
}

Same check in Python:

from tickstem import VerifyClient

client = VerifyClient(api_key=os.environ["TICKSTEM_API_KEY"])
result = client.verify("j8djk2@mailinator.com")

if result.disposable:
    raise ValueError("please use a non-disposable email address")
if not result.mx_found:
    raise ValueError("email domain does not appear to accept mail")

Same in Node.js:

import { VerifyClient } from "@tickstem/verify"

const client = new VerifyClient({ apiKey: process.env.TICKSTEM_API_KEY })
const result = await client.verify("j8djk2@mailinator.com")

if (result.disposable) {
  throw new Error("please use a non-disposable email address")
}
if (!result.mxFound) {
  throw new Error("email domain does not appear to accept mail")
}

What about catch-all and unverifiable domains?

A small caveat: mailbox-level verification (does this exact inbox exist?) is unreliable in 2026. Most mail servers run in catch-all mode at the gateway, accepting any address for the domain and bouncing later. SMTP probing — actually connecting to port 25 and asking the server — gets blocked by every major cloud provider as part of anti-spam policy.

For practical purposes, "the inbox accepts mail at the gateway" is the strongest signal you can get without sending the message. MX + disposable + role-based covers the cases that actually matter for signup flows. Catch-all aside, you do not need port 25 probing.

Comparison: blocklist vs MX vs full verification

Approach	Catches Mailinator	Catches new disposable domains	Catches typos	Latency
Regex only	No	No	No	0ms
Static blocklist	Yes	No	No	1ms
MX lookup only	No	No	Yes	50–150ms
Full verification API	Yes	Yes	Yes	80–200ms

One important caveat: never make signup completely dependent on a third-party API. If the verification service has an outage, your signup should fail open with a logged warning, not block legitimate users. Treat the result as a strong signal, not a hard gate when the network call itself fails.

What to put in the rejection message

The exact wording of the rejection message matters. "We do not accept Mailinator addresses" tells a knowledgeable attacker exactly which check you are running, and they will try the next service. Better:

Generic and polite: "Please use a non-disposable email address" — works, but obvious
Specific and informative: "This appears to be a disposable inbox. Please use a work or personal email address" — most useful for honest users who typoed
Best for security-sensitive flows: Accept the signup, mark the account as restricted, require additional verification (phone, SSO, credit card pre-auth) before unlocking the full feature set The third option is the safest pattern for high-value services. You never tell the attacker exactly what tripped the check, and you do not lose legitimate users who happen to use a service you do not recognise.

Mailinator alternatives users will try

For completeness, the most common disposable services users switch to when Mailinator is blocked:

Guerrilla Mail — @guerrillamail.com, @sharklasers.com
10 Minute Mail — @10minutemail.com, several rotating domains
Temp Mail — @temp-mail.org and similar
Yopmail — @yopmail.com
Maildrop — @maildrop.cc
EmailOnDeck — multiple rotating domains

All of these are covered by the maintained blocklists linked above. A blocklist-plus-MX-check stack catches them all.

Try it

The Tickstem verify API does the full check (syntax, MX, disposable, role-based) in a single call and returns a structured result. The Free tier includes 500 verifications per month — enough for most early-stage applications. Larger volumes are covered by Starter, Pro and Business plans.

Install the SDK in your language of choice:

Go: go get github.com/tickstem/verify
Node.js: npm install @tickstem/verify
Python: pip install tickstem

You can also try the verification with a single curl call against our public endpoint — see the verification documentation for details.

The status page that updates itself

Mike Tickstem — Tue, 12 May 2026 15:18:46 +0000

Most status pages lie.

Not intentionally — they just require a human to update them, and humans are busy, stressed, and dealing with the incident when the incident happens. So the status page says "All systems operational" while users are hitting errors, and the truth comes out twenty minutes later when someone finally posts "We are investigating reports of..."

The problem isn't laziness. It's that updating a status page is a manual step in the middle of an already chaotic situation. Your monitoring and your status page are disconnected.

The obvious fix

Connect them. If your status page is generated directly from your monitoring data, it updates the moment something goes wrong — no human required, no lag, no posts that trail the actual problem by 15 minutes.

Tickstem now ships status pages that do exactly this. Enable one in the dashboard, pick a slug, and your page is live at tickstem.dev/status/your-app. It reflects the current state of your uptime monitors and heartbeat monitors automatically.

No code required. No webhooks to wire up. If you already have monitors running, your status page is one toggle away.

What it shows

The page has two sections:

Services — your HTTP endpoints, pulled from uptime monitors, with current status and 30-day uptime percentage.

Scheduled Jobs — your background jobs, pulled from heartbeat monitors, with whether they're currently running and when they last pinged in.

That second section is where it gets interesting.

The gap other status pages miss

A status page that only shows HTTP endpoints can tell you your server is responding. It can't tell you whether your nightly data sync ran, whether the daily report job completed, or whether the backup that was supposed to finish at 3am actually finished.

Those are background jobs, and they fail silently. The server is healthy, the endpoint returns 200, but nothing useful is happening behind it.

Tickstem heartbeat monitors solve this by inverting the check: your job pings a URL after every successful run, and if the pings stop arriving, you get alerted. The status page surfaces this signal publicly — so your users see not just "API: Operational" but "Weekly digest: Running" or "Nightly sync: Missing".

from tickstem import HeartbeatClient, HeartbeatCreateParams

client = HeartbeatClient(os.environ["TICKSTEM_API_KEY"])
hb = client.create(HeartbeatCreateParams(
      name="nightly-sync",
      interval_secs=86400,
      grace_secs=3600,
))

# At the end of every successful run:
client.ping(hb.token)

If that ping stops arriving, your status page flips to "Missing" automatically.

Three steps to a live status page

Go to Dashboard → Status Page
Choose a slug and set a title
Toggle visibility to Public (Private mode could be used to preview or you can just keep the page private)

Your monitors and heartbeats populate it automatically. Set it to Private first to preview before sharing — the URL works for you while logged in, invisible to everyone else.

Free tier included. No credit card required.

GitHub: https://github.com/tickstem

Your Python cron jobs are failing silently. Here's how to fix it.

Mike Tickstem — Mon, 11 May 2026 20:07:18 +0000

If you're running a Python app on Vercel, Railway, Render, or Fly.io, you've run into this - there's no persistent process, so you can't use cron, APScheduler, or Celery workers the traditional way.
Most developers end up using the platform's built-in scheduled tasks — which work fine until they silently stop running and nobody notices for three days.

I built Tickstem to solve this, and just shipped a Python SDK.

The silent failure problem

Here's the thing about cron jobs: they fail in two ways.

Loud failures — the job runs, your endpoint returns 500, you get an alert. Fine.

Silent failures — the job never runs at all. Maybe a deployment broke something, maybe a config changed. The endpoint is healthy, no errors anywhere, but the job just... stopped. You find out when a user asks why their weekly report didn't arrive.

The second type is what kills you. Uptime monitoring doesn't catch it because your server is up. Error tracking doesn't catch it because there's no error. You need a dead man's switch.

Install

pip install tickstem

Requires Python 3.11+. One package, one API key, four tools.

Scheduling cron jobs

Instead of running a scheduler inside your app, Tickstem calls your HTTP endpoint on a schedule from outside:

from tickstem import CronClient, CronRegisterParams                                                                                                                                                                                                         

client = CronClient(os.environ["TICKSTEM_API_KEY"])

job = client.register(CronRegisterParams(
      name="send-weekly-report",
      schedule="0 9 * * 1",  # every Monday at 9am UTC
      endpoint="https://yourapp.com/jobs/weekly-report",
))

Your endpoint just needs to return 2xx. No SDK needed on the receiving side — it's just an HTTP call. This means it works on any serverless platform without touching your app's runtime.

The dead man's switch (heartbeat monitoring)

This is the part that actually solves the silent failure problem. Your job sends a ping after every successful run:

from tickstem import HeartbeatClient, HeartbeatCreateParams                                                                                                                                                                                                 

client = HeartbeatClient(os.environ["TICKSTEM_API_KEY"])

# Create once, save the token                                                                                                                                                                                                                               
hb = client.create(HeartbeatCreateParams(
      name="weekly-report",
      interval_secs=604800,  # expect a ping every 7 days
      grace_secs=3600,       # 1 hour buffer before alerting
))

# At the end of your job handler:                                                                                                                                                                                                                           
try:                                                      
      client.ping(hb.token)  # no API key needed — token is the credential
except Exception as e:
      logging.warning(f"heartbeat ping failed: {e}")  # non-fatal

If pings stop arriving within the window, you get an email. That's it. The ping endpoint doesn't require your API key — just the token — so you can call it safely from any context.

Uptime monitoring

While you're at it, monitor your actual endpoints too:

from tickstem import UptimeClient, UptimeCreateParams, Assertion

client = UptimeClient(os.environ["TICKSTEM_API_KEY"])

monitor = client.create(UptimeCreateParams(
      name="Production API",
      url="https://api.yourapp.com/health",
      interval_secs=60,
      assertions=[
          Assertion(source="status_code", comparison="eq", target="200"),                                                                                                                                                                                     
          Assertion(source="response_time", comparison="lt", target="2000"),
      ],
))

Assertions let you define what "healthy" actually means — not just that the server responded, but that it responded correctly and fast enough.

Email verification

One more thing in the bundle — validate email addresses before storing them:

from tickstem import VerifyClient                                                                                                                                                                                                                           

client = VerifyClient(os.environ["TICKSTEM_API_KEY"])

result = client.verify("user@example.com")
if not result.valid:
    raise ValueError(f"Email rejected: {result.reason}")
if result.disposable:
    raise ValueError("Disposable email addresses are not allowed.")

Checks syntax, MX records, 200+ disposable domains, and role-based prefixes (admin@, noreply@, etc). No SMTP probing.

One API key for everything

All four tools share one API key and one plan. Free tier includes 1,000 cron executions, 5 uptime monitors, 5 heartbeats, and 500 email verifications per month.

pip install tickstem

GitHub: https://github.com/tickstem/python
Docs: https://tickstem.dev/docs

Heartbeat monitoring: know when your scheduled jobs silently stop working

Mike Tickstem — Sun, 03 May 2026 02:53:12 +0000

Uptime monitoring tells you when your server goes down. But some of the worst outages look like this:

The server is fine
The cron scheduler fired
Nothing visibly broke

The job just quietly stopped doing anything useful.

A nightly data sync that hasn't run in four days. A backup that "completed" but wrote zero bytes. A report job that started silently throwing exceptions three weeks ago. These failures are invisible to a traditional HTTP monitor because the endpoint
never went down.

This is what heartbeat monitoring solves.

How it works

A heartbeat monitor is a dead-man's switch. Instead of Tickstem polling your endpoint, your job calls Tickstem at the end of every successful run. If the ping stops arriving within the expected interval + grace window, you get an alert.

You configure two things:

interval — how often you expect a ping (e.g. every 24h)
grace window — buffer past the deadline before alerting (e.g. 1h)

No ping for two consecutive intervals → alert sent.

Wiring it up

Go:

import "github.com/tickstem/heartbeat"

client := heartbeat.New(os.Getenv("TICKSTEM_API_KEY"))

hb, err := client.Create(ctx, heartbeat.CreateParams{
    Name:         "nightly-sync",
    IntervalSecs: 86400,
    GraceSecs:    3600,
})

// at the end of every successful run — token is the credential, no API key needed
if err := client.Ping(ctx, hb.Token); err != nil {
    log.Println("heartbeat ping failed:", err) // non-fatal
}

Node.js:

import { HeartbeatClient } from "@tickstem/heartbeat"

const hb = new HeartbeatClient(process.env.TICKSTEM_API_KEY)

const heartbeat = await hb.create({ name: "nightly-sync", interval_secs: 86400 })

// at the end of every successful run
await hb.ping(heartbeat.token).catch(err => console.error("ping failed:", err))

Or just curl — no SDK needed:

curl -s -X POST https://api.tickstem.dev/v1/heartbeats/$HEARTBEAT_TOKEN/ping

The token goes in the URL. No auth header. If curl fails, the script still exits cleanly.

The thing worth noting

The ping only happens on success. Silence means something went wrong — either the job crashed, was never scheduled, or completed without doing its actual work. That's the point.

Make the ping non-fatal though. A transient network blip shouldn't abort a successful sync.

When to use it

Any job where "it ran" and "it did something useful" are different things:

Database backups
Data sync / ETL pipelines
Report generation
Invoice or payment processing
Cache warming

Uptime monitoring and heartbeat monitoring are complementary. Uptime = server is alive. Heartbeat = job actually did its job.