Early access — 50% off forever for the first 100 customers

Find out that a cron job never ran before your customers do

Regular monitoring tells you the server is alive. It will not tell you the nightly backup has not started for three weeks. Tickwatch watches your job schedules — and shows the result to your customers on a public page.

  • 5 monitors free forever
  • no card required
  • 5 minutes to set up
crontab -e
# add one call at the end of your job
$
That is it. Nothing to install — no agent, no daemon, no access to your servers.
The blind spot

The server is green. There has been no backup for three weeks.

Uptime monitoring checks that a port answers. It has no idea you even have a nightly backup — let alone that it quietly stopped running.

What regular monitoring sees
api.example.ru200 OK
db.example.ru200 OK
worker-01200 OK
Everything is green.
And it says nothing about your jobs.
What Tickwatch sees
Nightly database backuphas not run in 21 days
Warehouse export12 min late
Report deliveryon schedule
You see the problem the same minute,
not when a customer asks you to restore their data.
Three steps

Five minutes from signup to your first alert

01

Create a monitor

Describe the schedule — a cron expression, an interval, or on demand. Time zone and grace period are configured separately.

Nightly backup · 0 3 * * * · Europe/Moscow
02

Add one line

The job reports in with a plain HTTP request. Works from anywhere — nothing to install or configure on the server.

curl -fsS https://ping.tickwatch.dev/$KEY
03

Hear only what matters

Silence from a job is the signal. We work out when the ping should have arrived and write to you only if it did not, or arrived with an error.

🔴 Nightly backup — did not run on time
0 s
deadline scan interval
not once a minute
0 KB
of run log inside the alert
stderr right in the message
0 days
of run history
on higher plans
0.0%
availability target for ping ingest
ingest runs apart from the dashboard
Works from anywhere

If it can make an HTTP request, it is already compatible

No SDKs, no agents. One curl at the end of the command and the job is on the map.

crontabsystemd timerKubernetes CronJobGitHub ActionsGitLab CIJenkinsAirflowCelery beatdbt Cloud
Laravel Scheduler1C EnterpriseBitrix agentsWindows Task Schedulern8nYandex Cloud FunctionsAWS EventBridgeSupervisorAnsible
Included in every plan

The status page competitors charge extra for

A public page on your own domain: components, incidents, maintenance windows and subscriptions for your customers. Powered by the same monitors — no manual upkeep.

status.yourcompany.com
Service status
Updated just now · automatically
Partial outage
Payment gateway99.55%
Nightly exports99.77%
Report delivery99.95%
Warehouse sync99.55%
InvestigatingWarehouse sync is not running02:14

This incident was created automatically: the “Warehouse sync” monitor did not report within its expected window. Updates will appear here and go out to subscribers.

RSSEmail subscriptionsWebhook on status change90 days of history

The page is served from a pre-computed snapshot and lives apart from the dashboard — it has to keep working precisely when something has gone wrong on our side.

Alerts

Notifications you will not want to mute

Monitoring dies from too many alerts, not too few: after two weeks of noise the team simply stops reading the channel. That is why fighting noise here is part of the product, not a setting.

One incident, one message
No repeat notifications while the problem is open. Recovery arrives as its own message.
Maintenance windows
One-off and recurring. Inside a window states are still tracked, but nobody gets woken up.
Failure threshold
A job that occasionally fails and retries itself will not raise the alarm on the first try.
Quiet hours and a kill switch
Configured per channel. Plus a single button that mutes every notification in the workspace.
This is what a message looks like
🔴 Nightly database backup03:12
finished with an error
Schedule
0 3 * * * (Europe/Moscow)
Exit code
1
Duration
4 min 12 s
Last run log: pg_dump: error: connection to server at "db-01" failed pg_dump: detail: FATAL: remaining connection slots are reserved backup.sh: exiting with status 1
Open monitorAcknowledge

The tail of stderr right inside the notification is usually enough to understand the cause without opening a laptop.

Telegram
free on every plan
Email
with the run log in the body
Webhook
HMAC signature, SSRF protection
Slack, Discord, Mattermost
incoming webhooks
Pricing

Priced in roubles, paid by card, with proper invoices

No exchange-rate maths and no surprises with cross-border payments.

Free
0₽ / mo
forever
  • 5 monitors
  • 7 days of history
  • 1 status page
  • Email and Telegram
  • Status page on our subdomain
  • One member
Start
490₽ / mo
  • 25 monitors
  • 30 days of history
  • 1 status page
  • Custom domain for the status page
  • Slack, Discord, webhooks
  • Up to 3 members
Most popular
Team
1,490₽ / mo
  • 100 monitors
  • 90 days of history
  • 3 status pages
  • SMS, 100 per month
  • SLA reports
  • Up to 10 members
  • Priority support
Business
3,990₽ / mo
  • 500 monitors
  • 365 days of history
  • 10 status pages
  • SSO and audit log
  • On-call schedules
  • Unlimited members
  • Contracts and invoices

Hitting a limit blocks creating a new monitor, but never switches off the ones already running. Breaking your monitoring over a late payment is the last thing we would do.

FAQ

What people usually ask

Uptime monitoring answers “is the service responding?”. We answer “did the job actually run?”. Those are different questions: a server can be perfectly healthy while the nightly backup has not run for weeks because someone deleted a line from crontab.

No. The job makes one HTTP request when it finishes. We need no agent, no daemon and no access to your infrastructure — we never connect to your servers at all.

Nothing. The next run is computed in the monitor's own time zone by parsing the cron expression, not by adding 24 hours. That is exactly why nightly jobs do not produce false alarms twice a year — a day with a clock change lasts 23 or 25 hours, and we account for it.

That is what the grace period and the separate duration limit are for. While the job fits inside the grace period nobody is disturbed. If it started and then hung for longer than allowed, that is a distinct kind of alert, because the cause is usually different.

Ping ingest and status pages run separately from the dashboard, and our scheduler pings an independent external service. If the scheduler stops, we hear about it — not you. Monitoring that quietly dies together with its customer is worthless.

Card payments in roubles. The receipt is issued automatically. For companies we prepare invoices and closing documents — billing details live in the workspace settings.

Monitors and notifications that already run keep running — we do not switch alerts off over a late payment. Only creating new ones is blocked, and limits drop to the free plan. Data is kept for another 30 days and can be exported.

Your first monitor — in five minutes

Five monitors free forever, no card. If it does not work out in ten minutes, write to us and we will sort it out together.