Skip to main content
A push check inverts the usual direction. Instead of Alertee reaching into your database, your cron job, script, or CI step POSTs a number to a private ingest URL. The pushed value runs through exactly the same condition engine as a SQL check — single-value or grid — and flows into the same incidents and alerts. That means:
  • Zero credentials. Alertee never holds a database password, and never opens a connection to you.
  • Works from a private network. Your job only needs outbound HTTPS. No bastion, no IP allow-list, no VPC peering.
  • Dead-man switch included. If nothing is pushed inside the staleness window, the check fails on its next scheduled run — so silence is an alert, not a gap.
Use it when the query you want to run can’t leave your network, when the number already exists in a script you run anyway, or when you’d rather not hand over credentials at all.

​
Creating one

Set a staleness window (how long the check tolerates silence, default 60 minutes) and a condition on the pushed value. Alertee mints an ingest URL when the check is saved and shows it to you — the token in that URL is the only credential, so treat it like a secret.
The condition describes the healthy state and the check alerts when it’s violated — greater_or_equal 100 is healthy at 100 rows and alerts at 99. See Conditions.

​
Pushing a value

Two body shapes are accepted. Send one or the other, never both.

​
A single number

​
Named rows (a grid)

One row per dimension — store, region, tenant, feed. Each name is a cell, evaluated against your per-cell condition. Up to 500 rows per push, and a name may appear only once in a batch.
There is no auth header — the token in the path is the credential, exactly as for a heartbeat ping. The CLI wraps the same endpoint, so a job that already has the CLI installed doesn’t need to hand-roll JSON (and doesn’t need to be logged in):

​
In a cron job

Run your own query, inside your own network, and push us the number:

​
How a push is evaluated

Each push is evaluated immediately — you don’t wait for the next scheduled run:
  1. The values are stored as the check’s latest batch.
  2. The condition is applied — single-value against value, grid per name.
  3. A run and result are recorded, so the value appears on the check’s chart and history like any other check.
  4. An incident is opened or resolved, and alerts route through the check’s alert group, honouring its grace period.
The response tells you what happened:
verdict is healthy, alerting, or error. alertee push prints it for you. Because grace-period state is shared with the scheduled path, a check pushed every minute alerts once per incident, not once per push.

​
Staleness (the dead-man switch)

The check’s own interval is what makes silence detectable. On each scheduled run Alertee reads the latest batch and compares its age to staleness_mins:
  • Latest value is inside the window → the condition is evaluated as normal.
  • Latest value is older than the window → the check fails with “No data received in the last N minutes”.
  • Nothing ever pushed → the check fails with “No data received yet” until the first push arrives.
Set the check’s interval at or below the staleness window, otherwise a stale check waits for the next run before it notices. Changing staleness_mins later never rotates the ingest URL, so a retune won’t break jobs already pushing.

​
Retention

Pushed samples are kept for 30 days and pruned daily. Only the most recent batch is ever evaluated. The durable record is the check’s run history, which follows normal check-result retention — so a value’s chart and incident trail outlive the raw sample.

​
Limits

​
Everywhere else

Available from the app (check type “Push a number”), the CLI (--type push, plus the alertee push command), and the MCP server (create_check with check_type: "push", which returns the ingest URL and an example curl).