Reading the Monitors page
Monitoring → Monitors in the panel at app.parsemend.com. The list is scoped to the organization you are in, across all of its projects.
Everything here is read-only. There is no create form, no edit form, and no delete action, because the SDK is the source of truth for a monitor's configuration. See how monitoring works.
The list
| Column | What it tells you |
|---|---|
| Monitor | The monitor_slug the SDK sent. Searchable |
| Status | Current state, as a colored badge |
| Schedule | 0 * * * * for crontab, every 1 hour for interval, - if none |
| Last check-in | When a check-in last arrived. Sortable |
| Next expected | When the next one is due. Sortable |
Rows sort by Last check-in, newest first, so a monitor that stopped reporting sinks to the bottom of the list. Sorting by Next expected ascending is the more useful view when you are actively looking for trouble: the most overdue monitor comes first.
Timestamps render twice, relative on top and exact underneath, so you can read "2 hours ago" at a glance and still correlate 2026-08-18 14:05 against a deploy log.
Status badges
| Badge | Color | Meaning |
|---|---|---|
ok | Green | The last run reported success |
error | Red | The last run reported failure |
missed | Red | A check-in was due and never arrived |
timeout | Red | A run started and never reported finishing |
unknown | Grey | Created, but no terminal check-in yet |
unknown is the state a monitor is born in. It persists if the job only ever sends in_progress and never a terminal status, which is worth noticing, because it means half your instrumentation is missing.
An in_progress check-in does not change the badge. The monitor keeps whatever status its last completed run left it in while the current run is underway.
Two columns worth checking on a new monitor
Schedule showing - means no monitor_config ever arrived. The monitor is recording check-in history and detecting nothing.
Next expected showing - means the same thing, or that the schedule that arrived cannot be turned into a next time: an unparseable cron expression, an interval of zero, or unit: 'year'. Either way the sweep skips this monitor, permanently and silently.
Those two columns are the whole health check for a newly wired-up job. If they are populated, detection is live.
The detail page
Click a row. The infolist repeats the list columns and adds the values that actually decide the timing:
| Field | Notes |
|---|---|
| Timezone | UTC unless the SDK sent otherwise. Only affects crontab |
| Check-in margin | In minutes. Shows the effective value, including the 5 minute default |
| Max runtime | In minutes. Shows the effective value, including the 30 minute default |
Both margin and runtime display the value being used, not only what the SDK sent. A monitor that never sent a margin shows 5 min here, because that is what the sweep will apply.
Check-in history
Below the infolist, one row per run, newest first:
| Column | Notes |
|---|---|
| Check-in ID | Truncated to 16 characters. Client-generated, unique per run |
| Status | ok, error, in_progress, or timeout |
| Duration | In milliseconds, or -. Only present if the SDK reported one |
| Environment | From the SDK's environment option |
| Release | From the SDK's release option |
| Started at | When the first check-in for this run arrived |
Each row is one run, not one request. A job that reports in_progress and then ok writes one row and updates it, because the row is keyed by the check-in id the SDK generated.
This is the view for answering "is it slower than it used to be". Duration across the last twenty runs tells you that quickly, and a job that is creeping toward its max runtime will show up here before it starts timing out.
An in_progress row that never moved to a terminal status, and is older than the max runtime, is a run that hung. The sweep marks it timeout on its next pass.
What is not here
No charts, no uptime percentage, no per-monitor notification settings. Alerting is configured once in Alert rules and applies to monitor issues alongside everything else. See failures, issues and alerts.