Skip to main content
Production Monitoring runs a group’s tests at a fixed time, on repeat. Use them for nightly smoke checks, regression catching, or monitoring key flows outside of PR activity. Disabled tests in the selected group are skipped. You can still run a disabled test manually from its test page.

​
Set up Production Monitoring

  1. Open Project → Tests tab.
  2. Pick the test group to monitor in the Test library rail - each production monitor runs a group you’ve already created.
  3. In the Run tests row under the group name, open the schedule menu (it reads Manual only until a schedule exists).
  4. Pick a frequency: Every 1, 3, 6, or 12 hours saves immediately. Daily, Weekly, and Custom schedule open a second step for the time, the day of week, or the cron expression, then Save schedule.
The schedule uses your browser’s timezone. Pick Manual to turn monitoring off again.

​
Monitor a staging or QA environment

Schedules run against Production by default. When the project has saved environments, the schedule menu shows an Environment select above the frequencies:
  1. Open the schedule menu and pick the environment (for example Staging).
  2. Pick a frequency, or keep the existing one. On an existing schedule the environment saves as soon as you pick it.
The schedule label reads, for example, Daily 9 AM on Staging, and each run opens the environment’s saved URL and applies its credential overrides. Deleting an environment moves any schedule that used it back to Production. PR Preview cannot be scheduled because each preview run needs a deployment URL.

​
Custom cron schedules

Pick Custom schedule when the presets don’t cover the cadence you need, for example weekdays only (0 8 * * 1-5) or every 30 minutes (*/30 * * * *). The expression uses standard 5-field cron syntax - minute hour day-of-month month day-of-week - and runs in your browser’s timezone. Seconds are not supported. Steps are evaluated inside each field’s own range rather than as rolling intervals, so 0 9 */14 * * runs on the 1st, 15th and 29th of every month rather than strictly every 14 days.

​
Schedules from the API or an agent

The same schedule is exposed on the public API as the group’s single schedule resource, and to MCP clients as get_group_schedule, set_group_schedule, and delete_group_schedule. Setting a schedule replaces the current one in place, so a rejected cron leaves the existing monitor running.
Presets (every_1h, every_3h, every_6h, every_12h, daily, weekly) take minute, plus hour for daily and hour and dayOfWeek for weekly. timezone is an IANA name and defaults to UTC when omitted. Add projectEnvironmentId to run against a saved environment; omit it for Production. Schedules are available for web projects only. See the API reference for the full request and response shapes.

​
Failure notifications

If any test in a monitored run fails, TesterArmy sends a failure summary to connected chat providers such as Slack or Discord. If no chat provider delivers, you’ll receive an email notification so you can act on it right away.

​
Tips

Keep each monitor focused. A monitor that tries to test login, billing, and settings in one go is harder to act on when it fails. Split those into separate groups instead.