← Back to Dashboard
JAMSHelp Center

JAMS Scheduler

When a JAMS Scheduler job fails, JAMS Incident Management calls, texts, emails, pushes, or messages your on-call team on Teams or Slack so a person actually finds out — instead of the failure sitting in a log until morning. You set this up as a JAMS Connection: name it, pick who gets alerted and how, set how long to wait before escalating, and JAMS Incident Management hands you a webhook URL plus a ready-to-paste PowerShell snippet to drop into a JAMS Notification Job.

Plan availability: The JAMS Scheduler integration is available on the Starter plan and up. See Plans & Billing.

JAMS is a two-way integration: JAMS tells JAMS Incident Management that a job failed, JAMS Incident Management alerts people, and the recipient can act on the job right from the phone — acknowledge to stop the escalation, or restart the failed job / continue or cancel its sequence or workflow. Those remediation actions run on your JAMS Server via the on-prem JAMS Incident Connector (see Two-way remediation below). Until the connector is installed and paired, the alert-and-acknowledge path works on its own and a chosen remediation action queues as "in progress" instead of executing.

Throughout this article, "JAMS" / "JAMS Scheduler" is the third-party job scheduler. "JAMS Incident Management" is this product.

What you'll get

After setup:

  • A JAMS job fails → its Notification Job POSTs to your JAMS Incident Management webhook → recipients get alerted on your chosen channels, in escalation order
  • The alert includes the job name, folder, status, reason, who submitted it, and (optionally) the tail of the job's log for one-click viewing from the dashboard
  • A recipient acknowledges from a voice call (press 1 or say "confirm") or by replying to the SMS — which stops the escalation for everyone in the group

What you'll need

  1. A JAMS Scheduler server where you can create or edit a Notification Job.
  2. JAMS Incident Management tenant-admin access (this page is admin-only).
  3. At least one recipient set up in JAMS Incident Management — an individual, a group, an on-call rotation, or a Teams channel.

Step 1 — Create a JAMS Connection

You can start two ways — both open the same form:

  • From /integrations/jams directly, or
  • From New Alert Flow (/flows/new) → choose the JAMS Scheduler source. It appears there whenever your plan includes JAMS, and jumps straight to the JAMS create form below.

Fill in the form:

  1. Name this Connection — e.g. jams-prod. This name doubles as the jamsCredentialRef in the PowerShell snippet, so pick something you'll recognize. One Connection per JAMS Server.
  2. Who gets notified? — add any mix of:
    • Individuals — specific people
    • Groups — expanded to their current members at notification time
    • On-call rotations — whoever is currently on call
    • Teams channels — post the alert to a shared channel (requires the Teams bot)
  3. Channels to use — Call, SMS, Email, Push, Teams, or Slack. Voice call is the most reliable for failure alerts (and the richest for remediation — the caller hears the full restart/continue/cancel menu). (Teams and Slack channel targets carry their own delivery, so per-user channels only apply to individual/group/rotation recipients.)
  4. Escalation interval (minutes) — how long to wait for each recipient to acknowledge before moving to the next one in the list.
  5. JAMS Incident Management Webhook Key — pick an existing webhook key or generate a new one. This is the JAMS Incident Management-side key; the Notification Job includes it in every call so JAMS Incident Management knows the request is yours.

Multiple JAMS environments? If you've paired more than one connector — one Agent per environment (e.g. Prod and Dev) — the form shows an Agent (JAMS environment) picker. Bind this Connection to the Agent for its environment so acknowledgements and remediations run only there: a Prod restart can never execute against your Dev server. With a single Agent the picker is hidden and there's nothing to choose. See Two-way remediation.

Click Save Connection. JAMS Incident Management then shows your ready-to-paste PowerShell snippet (Step 2) — copy it, then click View Flows to see the new flow in your list.

Why this matters: saving a Connection automatically creates a managed flow behind the scenes — one Connection = one flow. You manage recipients, channels, and the escalation interval here on the Connection. The same flow also appears in your Flows list, where Edit brings you right back to this form and Delete removes the Connection and its flow together.

Step 2 — Paste the PowerShell snippet into a JAMS Notification Job

When the Connection saves, JAMS Incident Management shows a PowerShell Notification Job snippet with your webhook URL, webhook key, and credential name already filled in. (You can re-open it later from the Connection's Show Snippet button.)

  1. Copy the snippet.
  2. In JAMS Scheduler, create (or edit) a Notification Job and paste the snippet into its source.
  3. The snippet's <<JAMS_NOTIFY_*>> tokens (job name, folder, status, reason, entry id, log file path, etc.) are JAMS Notification variables — JAMS substitutes the real values at runtime. Leave them as-is.
  4. Attach this Notification Job to any JAMS Job you want JAMS Incident Management to alert on. Point all of your jobs at the same Notification Job / webhook URL — JAMS Incident Management routes them through this one Connection.

The snippet posts a small JSON body to your webhook: a title and message ("JAMS Job X has failed"), severity, the failed job's metadata, and — if you keep the log block — the tail of the job's log so it's viewable from the dashboard.

Why this matters: the $credentialRef in the snippet must match the Connection name exactly. It's how JAMS Incident Management ties the incoming webhook to the right Connection (and its recipients).

Step 3 — Test it

Fail a JAMS job on purpose (or run the Notification Job against a known-failed entry). Within a few seconds the first recipient should get a call / SMS / email / push / Teams / Slack alert per your channel choices. Acknowledge it and confirm the escalation stops. If you've installed the connector, try a restart and confirm the job reruns.

You can also use Test Connection on the Connection row in /integrations/jams to probe reachability.

What you can do from the phone

The acknowledge experience matches the rest of JAMS Incident Management — see Voice Acknowledgement for the full call flow.

On a voice call

After the alert is read out, you'll hear an action menu built from the failed job and where it sits in JAMS. Acknowledge is always first; the remediation choices follow:

  • A standalone job → Acknowledge, Restart the job.
  • A job in a Sequence → Acknowledge, Restart the job, Continue the sequence (release it past the failed step), Cancel the sequence.
  • A job in a Workflow → Acknowledge, Continue the workflow (proceed past the failed step), Retry the failed job, Cancel the workflow, Cancel the job.

e.g. "Press 1 to acknowledge. Press 2 to continue the workflow Nightly-Billing. Press 3 to retry Upload-Payroll in Nightly-Billing…"

  • 1 / "confirm" → the alert is acknowledged. The escalation stops and every sibling notification in the group (the same alert sent to other people / channels) flips to acknowledged too. Acknowledging does not touch the job — use it when a person just needs to take ownership.
  • Restart / Continue / Retry / Cancel → the connector runs that action on your JAMS Server (see below). The alert is acknowledged as part of acting.
  • You can also say the action ("continue", "retry", "cancel") instead of pressing a key, and press repeat to hear the menu again.

On an SMS

Reply with the number of the action you want — 1 to acknowledge, or the digit next to restart / continue / cancel. JAMS Incident Management confirms, stops the escalation, and (for a remediation choice) dispatches it to the connector — same as the voice path.

Two-way remediation (restart / continue / cancel)

Remediation actions run on your JAMS Server through the on-prem JAMS Incident Connector — a small agent you install on the JAMS Scheduler host. It only makes outbound calls to JAMS Incident Management (long-polls for queued actions), so there are no inbound firewall changes.

Prerequisite — JAMS Scheduler REST API. The Agent runs remediations through your JAMS Scheduler REST API, so it must be installed and running first. During setup you point the Agent at your JAMS REST API URL, so install the Agent on a host that can reach it — simplest is the same server the REST API runs on (point it at localhost). If your REST API runs on a separate server, install the Agent on that server.

  1. On /integrations/jams, under Two-way remediation connector, generate a connector token (shown once) and copy it.
  2. Download the installer (.msi) and run it on the host with your JAMS REST API. Paste the token, then enter your JAMS REST API URL and credentials so the connector can act on jobs.
  3. Once it shows Online in the connector list, restart/continue/cancel choices execute for real.

If you are on the new JAMS API, one more step — and nothing will warn you. The new API reads job data straight from the database, but every action has to be handed to the JAMS Scheduler, and that hop is separate configuration. On most installs it needs SchedulerClient.config copied from the JAMS Scheduler folder (...\MVPSI\JAMS\Scheduler\) into the JAMS API folder, then a restart of the JAMS API Windows service.

Miss it and everything looks fine: setup passes, the Agent shows Online, job lists and statuses load. Only Restart / Continue / Cancel fail, with "JAMS accepted the request but could not reach the JAMS Scheduler". If you see that message this is almost always the cause — the Scheduler Connector is usually already registered, it is just invisible to the API. Creating one (ADD SCHEDULER CONNECTOR ... /CLIENTNAME=WebClient) is only needed if one genuinely does not exist.

The give-away is that reads work and every write fails. This does not affect the older username/password JAMS API.

Without the connector installed, the menu still plays and a chosen remediation action is accepted and recorded as in progress — it just won't execute until a connector is paired. Acknowledge always works regardless.

Running more than one JAMS environment? Install one connector (Agent) per environment, then bind each JAMS Connection to its Agent with the Agent picker on the Connection form (Step 1). A Connection's remediation is claimed and executed only by its bound Agent, so an action for one environment never runs against another's host. Cancel-suppression is scoped the same way. With a single Agent, Connections stay unbound and any Agent handles them — no change from before.

The available choices are built automatically from where the failed job sits:

  • Standalone or in a Sequence → Restart the job; a Sequence also gets Continue (release from wait) and Cancel.
  • In a Workflow → Continue the workflow (proceed past the failed step), Retry the failed job, Cancel the workflow, and Cancel the job. A workflow resumes differently from a sequence, so it offers Continue/Retry on the workflow rather than a plain job restart.

Every action is written to the audit log tagged with integrationSource: jams.

Editing and managing Connections

You can manage a Connection from two places — both land on the same form:

On /integrations/jams:

  • Edit — change the recipients, channels, escalation interval, Agent binding, or name. The webhook URL and key are unchanged, so you don't need to re-paste the snippet.
  • Show Snippet — re-display the PowerShell snippet for a Connection (handy when setting up a new Notification Job).
  • Test Connection — probe reachability.
  • Delete — removes the Connection and its managed flow. Inbound webhook keys are not deleted (manage those on /api-keys).

On your Flows list, a JAMS-managed flow shows:

  • Edit — opens the same Connection form (pre-filled) on the JAMS page.
  • Delete — removes the Connection and its flow together (same atomic delete as above).

Monitoring the JAMS services themselves

A failed job tells you JAMS is running. It doesn't tell you JAMS has stopped running — and a Scheduler that isn't up produces no failures at all, because it produces nothing.

The JAMS Service Monitoring card on this page watches the JAMS services on each paired server and pages you when one stops. Two things make it useful during an incident rather than after it:

  • Attempt to start. A stopped-service alert carries a start action, and the same button appears on the dashboard — so the first responder can try the obvious fix from the alert itself.
  • Queue depth. The Agent reports MSMQ queue depth, and you set the threshold. A breach has to be sustained before it pages, so a brief spike during a busy window doesn't wake anyone, and you get a recovery notification when it clears.

A silent Agent is not the same as a stopped service. If a server is powered off, every service on it is technically not running — but we haven't seen them stop. Those services show Unknown, not Stopped, and the Agent going quiet raises its own alert instead. A page saying "the Scheduler stopped" when the truth is "we can't see that machine" sends somebody to fix the wrong thing.

Non-JAMS Windows services are monitored from a separate page with its own recipients — see Windows Service Monitoring. The split is deliberate: whoever should hear that a JAMS job failed often isn't whoever should hear that a SQL Server service stopped.

When the connector is offline

Remediation depends on the Agent reaching out to collect queued work. If it isn't running, a Restart, Continue or Cancel still queues successfully, the caller is told "still in progress, you'll get an update shortly" — and nothing ever runs. No error, no failed notification.

This page shows a non-dismissible amber banner whenever an Agent is paired but none is reporting, so that state is visible before somebody discovers it mid-incident. It only appears if you have an Agent paired, so a Connection that doesn't use remediation is never nagged.

A connector pointed at the wrong environment looks identical to one that's offline. Pairing tokens are per-environment, so an Agent paired against a different environment authenticates against nothing and simply never appears. If an Agent is installed and running but never shows as reporting, check which environment its token came from before anything else.

Troubleshooting

SymptomLikely causeFix
No alert when a job failsThe Notification Job isn't attached to the job, or the webhook URL/key is wrongConfirm the Notification Job is attached and re-paste the snippet via Show Snippet.
Restart / Continue is accepted but never runsNo Agent is reportingLook for the amber connector banner on this page; check the Agent's Windows service is running on the JAMS host.
A service shows UnknownThe Agent hasn't reported recently enoughCheck the Agent service is running and the host has outbound internet access.
An enabled monitor pages nobodyNo alert flow chosen, or the flow was deleted, deactivated, or has no reachable recipientThe card names which of these applies — pick a flow, or fix the flow's recipients.
Webhook reaches JAMS Incident Management but no one is alertedThe Connection has no valid recipients, or recipients lack the chosen channelRe-check recipients and channels in the Connection; confirm phone/email/Teams details on the people.
Acknowledge says "JAMS credential reference missing"The snippet's $credentialRef doesn't match the Connection nameSet $credentialRef to the exact Connection name.
Recipients aren't getting SMS or callsChannel / opt-in / phone-format issueSee Recipients aren't getting SMS or calls.

What's next