DEV Community: Mike Tickstem

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.

How to Add Uptime Monitoring to a Next.js App on Vercel (With SSL Alerts and Response Assertions)

Mike Tickstem — Sat, 02 May 2026 15:00:48 +0000

The Problem

Vercel tells you when a deployment fails. It doesn't tell you when your app is down at 3am on a Saturday.

There's no built-in uptime monitoring on any Vercel plan. If your API route starts returning 500s, or your SSL cert is two weeks from expiring, you find out when a user reports it — not before.

The Solution

Register your endpoints with an external uptime monitor. It polls your URLs on a schedule, checks that responses look healthy, and emails you the moment something goes wrong.

The approach is straightforward:

Tickstem → GET https://yourapp.vercel.app/api/health → assert status 200 + body contains "ok"

Implementation

Install the SDK:

npm install @tickstem/uptime

Create a scripts/setup-monitors.ts file you run once (or in CI after each deploy):

import { UptimeClient } from "@tickstem/uptime";

const client = new UptimeClient(process.env.TICKSTEM_API_KEY!);

await client.create({
    name: "Production API",
    url: "https://yourapp.vercel.app/api/health",
    interval_secs: 60,
    assertions: [
      { source: "status_code",   comparison: "eq",       target: "200" },
      { source: "response_time", comparison: "lt",       target: "3000" },
      { source: "body",          comparison: "contains", target: '"status":"ok"' },
    ],
  });

console.log("monitor registered");

Your health route:

// app/api/health/route.ts
export async function GET() {
  // optionally check DB, Redis, etc.
  return Response.json({ status: "ok" });
}

That's it. Tickstem will poll the endpoint every 60 seconds and email you if any assertion fails — not just if the server is unreachable, but if it returns the wrong status code or the body doesn't look right.

Why assertions matter

A plain ping-check only tells you the server responded. It won't catch:

Your health endpoint returning 200 with { "status": "degraded" } because the DB is unreachable
A middleware bug that returns 200 for every route including ones that should 404
Response times that have quietly climbed from 200ms to 4 seconds

Assertions let you define what healthy actually means for your specific endpoint.

SSL certificate expiry

For any HTTPS endpoint, Tickstem automatically captures the SSL certificate expiry date on every check. When a cert is within 30 days of expiry you get an email alert — before it affects users.

const checks = await client.checks(monitorId, { limit: 1 });
console.log(checks[0].ssl_expires_at); // "2026-08-14T00:00:00Z"

Checking status programmatically

You can query check history from anywhere — useful for CI gates or status page scripts:

const monitors = await client.list();

for (const m of monitors) {
  const checks = await client.checks(m.id, { limit: 1 });
  console.log(`${m.name}: ${checks[0]?.status ?? "no checks yet"}`);
}

Key benefits

Works on any Vercel plan including free tier
Assertions catch logical failures, not just connectivity
SSL expiry alerts before users see the browser warning
Check history retained (7 days on Free, up to 90 days on Pro)
One API key covers cron jobs, uptime monitoring, and email verification — no separate accounts

Free tier includes 5 monitors. Dashboard at https://app.tickstem.dev.

How to add cron jobs to a Next.js app on Vercel (without upgrading to Pro)

Mike Tickstem — Thu, 23 Apr 2026 18:21:55 +0000

If you've built a Next.js app on Vercel and needed a scheduled job — a digest email, a daily cleanup, a sync — you've probably hit the same wall: Vercel's cron jobs are Pro-only, and the free tier limits you to once per day.

Here's how to get reliable cron jobs on any Vercel plan, including free.

The problem with Vercel cron

Vercel added native cron support, but with significant limitations:

Pro plan required — not available on Hobby
Once per day maximum on Hobby even if you upgrade
No execution history — if your job fails silently, you won't know
No retries — one failure and it's gone

For anything serious you need something external.

The approach

Your Next.js app already exposes API routes. A cron service just needs to call one of those routes on a schedule. Your endpoint does the work and returns 2xx — that's the whole contract.

Scheduler → POST https://yourapp.vercel.app/api/jobs/cleanup → 200 OK

No always-on server. No infrastructure to manage.

Setting it up with @tickstem/cron

Install the SDK:

npm install @tickstem/cron

import { CronClient } from "@tickstem/cron"

  const cron = new CronClient(process.env.TICKSTEM_API_KEY)

  await cron.register({
    name: "daily-cleanup",
    schedule: "0 2 * * *",   // every day at 02:00 UTC
    endpoint: "https://yourapp.vercel.app/api/jobs/cleanup",
  })

Your API route just needs to return 2xx:

  // app/api/jobs/cleanup/route.ts
  export async function POST(req: Request) {
    if (req.headers.get("x-tickstem-secret") !== process.env.CRON_SECRET) {
      return new Response("unauthorized", { status: 401 })
    }

    // do your work
    await cleanupOldRecords()

    return new Response("ok")
  }

Set CRON_SECRET to a random string (openssl rand -hex 32) in both your Vercel environment variables and your Tickstem job headers:

  await cron.register({
    name: "daily-cleanup",
    schedule: "0 2 * * *",
    endpoint: "https://yourapp.vercel.app/api/jobs/cleanup",
    headers: { "X-Tickstem-Secret": process.env.CRON_SECRET },
  })

What you get

Runs on any Vercel plan, including free
Any schedule — every minute, every 15 minutes, whatever you need
Execution history so you can see what ran and what failed
Automatic retries on failure
Dashboard at https://app.tickstem.dev

Free tier includes 1,000 executions per month — more than enough for most side projects.

Common schedules

*/15 * * * * every 15 minutes
0 * * * * every hour
0 9 * * 1 every Monday at 09:00 UTC
0 0 1 * * first of every month

Use https://crontab.guru to build expressions.

That's it. Your endpoint stays on Vercel, the scheduler runs externally, and you're not locked into any platform's billing tier.