Can you post your script? if you run your script locally instead of through self service what happens? run it with a

sh -verbose /path/to/script.sh

and see what responses you get.

How many times did you run your test? I'm wondering if it was because the natural Launchd triggered check-in had already engaged and was just waiting out the random delay timer. You'll see this sometimes just running sudo jamf policy in Terminal. It will sometimes come back with, 'trigger already running' or something to that effect. When that happens you can't force another check-in to occur without first killing the jamf process.

Also, do you scope your policies to be limited to a certain group of users? Or do your users sign into self service? I think I recall that some things will not work if it's not scoped and they sign in or vice versa.

Here is the script:

!/bin/bash

sudo jamf policy; sudo jamf recon

It is scoped to specific computers.
I have run it on a few different computers with the same result. Also, if I run sudo jamf policy in Terminal first to make sure its not already running when I run the script from Self Service I get the same results.

Running sudo jamf policy in Terminal results in the recurring check-in policies running as expected.

If that's your script, check your syntax. (missing #)

!/bin/bash
sudo jamf policy; sudo jamf recon

Your shebang isn't a shebang

#!/bin/bash
sudo jamf policy; sudo jamf recon

Oops sorry the # is there. I assume the forum used it to bold and enlarge the line.

I would run the recon first so the device can identify what scopes it is in before running the policy (recurring checkin). You can also drop the sudo since all scripts run as root via self service. I would also look at doing this with a Files and Processes policy payload rather than a script. Just enter

jamf recon && jamf policy

In the Execute command text field.

I tried creating a new policy with the maintenance payload for update inventory and "Files and Processes" "Execute Command" jamf policy

This had the same results. Inventory updates, it checks-in (or at least updates the check-in time), policies fail to trigger.

So I wonder if you need to reach out to your Jamf Buddy to get clarification if this is an expected action or not. I tested by creating a dummy policy that does nothing other than just executing a policy. It works fine when I run it as a local script, but when that script is executed by policy through self service, nothing happens. There's no log created, so I wonder if its something related to the fact that jamf policy can't run when another policy is already executing similar to this

Mac mini:~ admin$ /usr/local/bin/jamf policy
This policy trigger is already being run: root             13965   0.0  0.1  4321604  16028   ??  Ss    1:29PM   0:00.05 /usr/local/jamf/bin/jamf policy -randomDelaySeconds 300

And I believe from experience only one policy an execute at any given time. I think that's different than having a policy call another policy with
1. Policy executes
2. Policy calls a 2nd action by executing a command under files and processes.
In that scenario, I think policy a completely finishes before policy b runs.