Reliability
The health board, scheduled jobs, data runs, collectors, email delivery, deploys and database health.
When something is broken, these screens tell you what and since when. Work them in the order below during an incident.
Before you start
- Any staff role can open the health board. The rest need platform-control read access, which every staff role has.
- None of these screens changes anything. They report.
Incident order
Check the board
Open /admin/health and read the overall state.
Check when it last ran
Read the "watch last ran" line before you trust anything green.
Check the scheduled jobs
Open /admin/ops/crons for silent, failing and stuck jobs.
Check the deploy
Open /admin/ops/deploys and read what production is running.
Check the database
Open /admin/health/db if queries are slow.
The health board
The board shows the overall state, each component, how many are down and how many are warning, and watch last ran.
A green board means nothing if the watch has not run for an hour. Read the "watch last ran" line first, every time. A stale board is the failure mode this line exists to catch.
The board and the alerting use the same checks on purpose. A board and an alert that compute "degraded" separately always disagree during an incident.
Scheduled jobs
Two screens look similar and are not.
| Screen | What it is |
|---|---|
| /admin/ops/jobs | The configured schedules and the event-driven workflows. It shows what should exist |
| /admin/ops/crons | The record of what actually ran. Use this one for outcomes |
On the jobs screen, "last related activity" is derived from side effects, not from a run record. It can look healthy when nothing ran. Confirm on the cron runs screen.
The cron runs screen has four tiles worth knowing:
- Silent 7d. No run recorded in a week. The schedule is not firing at all.
- Failing. Runs are recorded and they fail.
- Stuck. A run started and never finished.
- Runs 7d. The healthy baseline.
When the ledger is empty it reads "No run has been recorded yet. The ledger fills as the crons fire."
The report digest job exists but is not on a schedule today, so it never fires by itself. Do not chase it as a silent job.
Event-driven workflows
Some work is driven by events rather than a clock: outreach follow-ups, payout follow-ups, draft and dispute service-level chases, dunning reminders, contract reminders and thank-you messages.
Automation sends reminders and re-queues work. It never moves money. The single exception is dunning, which suspends a licence automatically after 14 days past due.
Data runs and spend
| Screen | What it answers |
|---|---|
| /admin/ops/apify-spend | Spend today, spend over 30 days, runs, running now, failures, average cost per run, broken down by purpose, workspace, surface and trigger |
| /admin/ops/apify-runs | Every run over 30 days, with the estimate beside the actual |
Three run states are called out with filter chips:
- Stranded. Still running after hours. Cyrqle was charged and nothing was ingested, because the completion callback never arrived.
- Failed or aborted.
- Returned nothing.
The cost estimates are not calibrated. One data source measured several times over its estimate. Treat an estimate as a lower bound and read the actual afterwards.
Collectors
/admin/ops/collectors lists every collector source across every workspace.
The number this screen exists for is uncapped monitors. A monitored source with no budget spends every cycle, forever, and the workspace cannot see it. Work this list before you work spend.
Filter by "on a cadence", "cadence, no cap" and "overdue for a run". Monthly cadence uses a 33-day window.
Manual ingestion
/admin/ops/ingestion shows add-post-by-link runs. Anything pending or running for more than 15 minutes is stuck.
The customer's dialog polls with no timeout. A stuck run spins on their screen forever. Clear stuck runs the same day and tell the customer to close the dialog.
Email and notifications
| Screen | What it answers |
|---|---|
| /admin/ops/email | Bounces grouped by recipient domain |
| /admin/ops/notifications | Every notification kind against what was actually sent |
Delivery is shared across every workspace on the sending domain. One brand mailing a stale list damages delivery for all of them. Escalate a rising bounce rate immediately.
On the notifications screen, three shapes matter: never sent, meaning a notification kind with no rows at all and therefore unwired or broken; unread walls; and opt-out rates, where anything above 20 percent means something. Notification contents are deliberately not shown.
"No provider id" on the email screen means the message cannot be matched to a bounce at all. It is worse than unconfirmed, not better.
Tracking ingest authentication
/admin/ops/ingest lists every brand sending storefront traffic, how it authenticated over the last week, and why its last unverified request failed. Read it before you change the ingest auth setting on /admin/controls.
Deploys and incidents
/admin/ops/deploys shows the commit, branch and message production is running, taken from the build itself. Below it: job failures grouped by job and by day, and a table of recent staff changes with the operator and their reason.
Start an incident by comparing the failure onset with the deploy time. Most incidents start at a deploy.
Database health
/admin/health/db shows database size, table and index counts, connections, bloated tables, and unused index bytes, plus a per-table breakdown. A bloated table is one where dead rows exceed 20 percent of live rows.
This screen covers runtime database health only. Schema checks are done by engineering with their own tooling.
Seed and demo data
/admin/ops/seed shows which demo workspaces exist and whether their content is still there. Demo workspaces force payouts and ad boosts onto the test path, so a demo can never spend.
A demo proves the screens work. It proves nothing about money, because a demo cannot spend. Never validate a payment fix on a demo workspace.
Pitfalls
- A green health board proves nothing on its own. Read "watch last ran" first, every time.
- The jobs screen shows what should run. The cron runs screen shows what did run. Answer an incident from the second one.
- Cost estimates on the runs screen are not calibrated. Read the actual figure, not the estimate.