All your scheduled jobs in one place. Your servers stay closed.

Crontab is fine on one machine you look at every day. It keeps no history, so a job that failed last Tuesday left nothing behind to look at, and a machine that was down at 03:00 simply skips the run with nothing anywhere to say it was missed.

Those watch cron from the outside: you add a ping to the end of your script and they tell you when it stops arriving. Runjet is what runs the script, so the output and the reason it stopped are already here, and there is no ping to forget on the job you add next week. They send a message when a job stops reporting; Runjet sends one when it breaks and one when it recovers, and nothing for the ninety-eight failures in between.

No. Every connection is made by the agent, outward, over HTTPS. Nothing is listening on your side, there is no port to forward, and the service has no route in even if it wanted one.

Anything you would put in crontab: a shell one-liner, a script, a docker exec. The agent runs it under an account of its own, runjet-job unless you name another, so a job cannot read the agent’s key or your secrets file, and hands back the exit code and the output — it does not need your work wrapped in anything of ours.

The command, the schedule, the exit code and whatever each run printed — the same things the interface shows you. Of each agent I also see the name you gave it, its version, operating system and architecture, the account it runs jobs under, and the address it connects from. The agent sends results, not files: nothing else on the machine leaves it.

It does not start a second one. A job runs once per machine at a time, so a tick that comes due while the previous run is still going on that agent is dropped rather than queued — an hourly job that takes ninety minutes runs every two hours and never piles up behind itself. What that costs you is a line in the history: a dropped tick leaves no row, so the list shows the runs that happened rather than the times the machine was still busy. Pressing the play button in the same situation is the case where you are told, because there is somebody there to tell: the answer names the machine and what is already in flight on it.

A smaller plan holds less, so buying one asks what to turn off. If the workspace has more agents or more people in it than the plan allows, the purchase does not go through until you have chosen which of them stop — and stop is what they do: they are switched off, not deleted, and they stay off until you are on a plan with room again, where you turn back on whatever you want. Jobs whose last agent goes are named before you confirm, because a job with nowhere to run stops quietly. Log text is the exception in your favour: a shorter window never reaches backwards, so everything written under the longer one stays readable and the new window applies from that day on. Run history is not a plan axis at all — every run is kept on every plan.

Reminders are scheduled for the last days of the trial, and no card was taken to start, so nothing is charged when the date passes. Then the scheduler stops: nothing runs, but everything stays readable for another 30 days and export still works — subscribe inside that window and your jobs, history and agents are exactly as you left them, with scheduling starting again from that moment rather than firing everything it missed. After it the workspace comes down, and for 30 days more it can still be brought back if you ask, before it is deleted for good. A subscription that ends later puts you on the same ladder from its own last day, and either way emails are scheduled on the way down, each counting the days that are left. Treat them as a courtesy rather than a clock, because an email can arrive late, and export before the 30 days are out: once the workspace comes down there is nothing left to export.