Feature request for product/service
Cursor Web
Describe the request
Feature request for product/service
Cursor Web / Automations (also visible in the IDE Automations editor)
Describe the request
Cursor Automations support scheduled triggers via cron expressions (e.g. 0 9 * * 1-5). That is flexible, but raw cron is hard to read at a glance — especially for teammates who did not configure the automation.
Problem: In the Automations UI, users often see only the raw cron string. Interpreting it requires mental parsing of five fields (minute, hour, day-of-month, month, day-of-week). Common mistakes include misreading day-of-week (1 = Monday in standard cron) or assuming a timezone that is not shown.
Requested feature: Display a short, human-readable description next to (or below) the cron expression wherever a scheduled trigger is shown.
Examples:
| Cron expression | Human-readable label |
|---|---|
0 * * * * |
Every hour at minute 0 |
0 9 * * * |
Every day at 9:00 AM |
0 9 * * 1 |
Every Monday at 9:00 AM |
0 9 * * 1-5 |
At 9:00 AM, Monday through Friday |
30 14 1 * * |
At 2:30 PM, on day 1 of the month |
Where this should appear:
- Trigger editor — below the cron input / custom expression field, updating live as the user types
- Automation list & detail view — so you can scan schedules without opening each automation
- Run history (optional) — confirm when the automation is expected to fire next
Suggested UX:
Schedule
┌─────────────────────────────────────┐
│ 0 9 * * 1-5 │ ← editable cron field
└─────────────────────────────────────┘
Runs at 9:00 AM, Monday through Friday ← human-readable helper text
For preset schedules (“Every hour”, “Every day”, etc.), the readable label can match the preset name. For custom cron, generate the label from the expression.
Edge cases to handle:
- Invalid cron — show the raw expression only, or a gentle “Could not parse schedule” message; do not block save if the expression is valid server-side but fails client-side parsing
- Ambiguous timezone — cron has no timezone field today; label should avoid implying one unless the product already displays timezone elsewhere (e.g. “9:00 AM (account timezone)” if that exists)
- Non-English locales — nice-to-have: localized descriptions later; English-first is fine for v1
- Power users — keep the raw cron visible and editable; the description is a helper, not a replacement
Why this matters:
- Reduces misconfiguration (e.g. weekend runs when weekdays were intended — related to weekday scheduling requests on Cursor forum)
- Makes automations easier to review in teams (especially with config-as-code discussions on Cursor forum)
- Mirrors what many cron UIs already do (GitHub Actions, CloudWatch, etc.)
Suggested implementation sketch (pseudocode — not a full repo):
// UI: show helper text under the cron input
function CronTriggerField({ cron, onChange }) {
const label = describeCronSchedule(cron);
return (
<>
<input value={cron} onChange={onChange} />
{label && <p className="helper">{label}</p>}
</>
);
}
// Core helper — wrap any cron→text library (e.g. cronstrue)
function describeCronSchedule(cron: string): string | null {
const trimmed = cron.trim();
if (!trimmed) return null;
try {
return cronstrue.toString(trimmed, { use24HourTimeFormat: false });
} catch {
return null; // hide helper, keep raw cron visible
}
}
// Presets can skip parsing and use fixed copy
const PRESET_LABELS = {
"0 * * * *": "Every hour",
"0 9 * * *": "Every day at 9:00 AM",
// ...
};
Existing libraries like cronstrue handle the parsing; this is mostly a thin UI wrapper.
Happy to help test or iterate on copy/UX if useful.
Operating System (if it applies)
MacOS
Expected the automation to run at 9:00am Paris time but it did at 11:00am 