Terms of Service

1.Agreement

These Terms of Service (the Terms) are a contract between the Provider and the Customer about the use of the Service. They apply to every Workspace and to every Account and API token within it. By registering a Workspace, by buying a Plan, or by using the Service, the Customer accepts them. Capitalised words are defined in the section Definitions.

The Provider is Tomáš Jablonický, a sole trader registered in the Czech Trade Licensing Register (živnostenský rejstřík), Company ID (IČO) 87666570, with his place of business at Severní 1477/3, Děčín VI-Letná, 405 02 Děčín, Czech Republic. The Provider is not registered for value added tax. One person builds and runs the Service and reads every message sent to it. Nothing in these Terms implies a support organisation.

Three documents apply. These Terms govern the hosted Service. The Runjet Agent Licence governs the Software the Customer installs on its own machines; the section The Agent and its Licence says how the two fit together. The Privacy Policy at runjet.dev/privacy and the GDPR notice at runjet.dev/gdpr describe how personal data is handled; they are separate documents and these Terms do not restate them. Where the Terms and the Licence describe the same thing in different words, the Licence governs the Software and the Terms govern the Service.

These Terms exist in English and in Czech. The Czech text prevails wherever the two differ in meaning; the English text is a translation for convenience. The Licence makes the same choice in its Article 10, and one product does not give two answers.

2.The Service

Runjet is a hosted scheduler for cron-style jobs that run on the Customer’s own machines. The Customer defines a job: a command, a five-field cron schedule, the Agents it runs on, tags, and the names of secrets. The Service decides when a job is due, hands the command to the Customer’s Agents, and records what each run reports: status, start and end, duration, exit code, and the text the command printed. A dashboard at app.runjet.dev shows all of it. Emails go out when a job fails and when it recovers, per job and per Agent; when an Agent has been silent for ten minutes; and when a run has gone on longer than eight hours; that threshold can be set per job, and crossing it does not stop the run.

Runjet never executes the Customer’s command. A command runs on the Customer’s machine, inside the Software, which the Customer installs by hand. The Service cannot start a process, cannot see the machine, and holds no part of the environment in which the command runs. The Service schedules, transmits, records and displays. Everything in these Terms about responsibility and liability follows from that fact.

The Software connects outward to the Service over HTTPS; nothing connects inward and the Software opens no port. Commands are signed with the Workspace’s key and the Software verifies the signature before it runs anything. The Software authenticates by signing its own requests, not with a shared secret.

The Service holds no secret values. A job names its secrets; the values live in a file on the Agent’s host and never leave it. The one place a secret can reach the Service is the run output, which is whatever the command printed. The Software masks the values of declared secrets in output before sending it. That masking is a net, not a boundary: the Customer, not the Service, decides what its commands print.

What the Service sees of a job is the command text, the schedule, the exit code, the output, and of each Agent its name, version, protocol, operating system and architecture, the name of the account it runs jobs under, and the IP address it reports in from. To that is added the account data described in the section Legal form, Customer and Accounts. An Agent’s name is typed by the admin who enrols it and is commonly the name of the machine. The Service does not see the machine, the files on it, the secrets file or the Agent’s private key.

The following is how the Service behaves, and each item is a way a job can fail to run when somebody expected it to. (a) A job runs once per Agent at a time; a scheduled occurrence that falls while the previous run is still going on that Agent is dropped and leaves no record. (b) Catch-up is off by default and is switched on per job. With catch-up off, an occurrence missed while the Agent or the Service was unavailable is dropped. With catch-up on, one run is made up at the next opportunity however many occurrences were missed; the Service waits for an absent Agent at most 24 hours, and one minute for an ordinary run, before it records the occurrence as skipped. (c) A run has no time limit on any Plan; an alert replaces a deadline. (d) Schedules fire in the Workspace’s timezone, chosen at registration and changeable; a zone the Service does not know falls back to UTC. (e) A suspended Workspace schedules nothing, and resuming it does not run what was missed. (f) An Agent whose protocol version falls outside the window the Service serves is refused with HTTP 426, and its jobs stop on that host until the Customer upgrades the Agent. The Agent list marks an Agent speaking an older protocol version than the Service serves, including while it is still being served; that mark is the only warning, the Customer sees it only by opening the list, and nothing is promised about how long it shows before the bottom of the window moves. (g) Dispatch latency is about a second, and no number is promised.

The Provider’s obligation is therefore this: to make due jobs available to the Customer’s Agents and to record what they report, with reasonable care. The Provider does not promise that a job runs at a particular time, or at all. The Customer is responsible for monitoring any process on which its business depends and for having an alternative when a run does not happen.

3.Legal form, Customer and Accounts

The registration form asks who is registering, and one answer is required with nothing preselected: an individual, meaning a natural person acting outside their trade, business or profession; a sole trader, with an optional registration number; or a company, with a required registration number. The answer is a declaration. The Provider records it, relies on it, and does not verify it against any register or present it as verified. It decides which provisions of these Terms apply and whether consumer protection applies. It is not a tax status: tax is decided at the payment provider from what the Customer enters there, and neither is derived from the other.

The consumer provisions of these Terms apply to a Workspace registered as an individual. A person acting in business who registers as an individual receives protection they are not owed, and the Provider accepts that. A consumer who registers as a sole trader or a company does not lose the rights that mandatory law grants consumers; those rights apply regardless of the declaration.

The declared legal form can be changed on the Workspace screen until the first payment. After the first payment the application refuses the change and the Customer writes to hello@runjet.dev, because a change of legal form after payment is a change of contracting party and not a setting. Every change is recorded in the audit log.

The Customer is whoever registered the Workspace, in the declared legal form. Each Workspace has one billing address, which is the registration email; every email about the life of the Workspace goes there. The Customer answers for every person it invites into the Workspace and for everything done under the Accounts and API tokens of the Workspace. One Customer may hold several Workspaces; each is its own Subscription and its own contract under these Terms.

An Account is one person’s login inside a Workspace, with one of three roles: viewer, operator or admin, in ascending order of what it can do. The person who registers is the first admin. Every further Account is created by an emailed invitation link; nobody is ever given a password by somebody else. A password reset uses a six-digit code valid for ten minutes and five attempts, and a reset ends every session of the Account. A session expires thirty days after signing in; using it does not extend that. Blocking, deleting or demoting an Account takes effect on its next request. The Service also serves API tokens, which carry their own role and are shown once; anything done with a token is done by the Workspace.

The Plan limits the number of Accounts, as published in the price list: Solo one, Pro five, Business unlimited. A seat is taken when an invitation is sent. Blocking an Account does not release its seat; deleting the Account does.

An audit log records who did what in the Workspace, with names and IP addresses. It is kept for as long as the Workspace exists.

The Customer keeps the Service secure on its side. That means: (a) the credentials of every Account; (b) enrolment tokens, which are single-use, expire in an hour, and are visible in the host’s process list unless passed by file or standard input; (c) the private key of each Agent on each host; (d) the hosts themselves; (e) running jobs under a separate, least-privilege account so that a command cannot read the Agent’s key or its secrets file; (f) installing the Software as the documentation at docs.runjet.dev describes and installing its updates without undue delay; and (g) not sharing Accounts to evade seat limits. These duties match Article 6 of the Licence.

The Provider refuses registrations from throwaway email domains and reserved Workspace names, limits login, signup, confirmation and reset attempts to ten a minute per client, and marks an unfinished registration expired and clears the password from it once its confirmation link runs out, which is after 48 hours. The Provider may refuse, or reclaim with notice, a Workspace name that infringes the rights of others or is abusive.

4.Plans, prices and payment

The Service is sold in Plans. The Plans, their prices and their limits — Agents, Accounts, output kept per run, and the window for which log text is kept — are published at runjet.dev/#pricing and in the application’s plan picker. The price list in force at the moment of purchase is the price the Customer pays. Prices are in US dollars. Scheduled jobs are unlimited on every Plan, and a run has no time limit on any Plan.

The Customer pays through Stripe. The checkout is Stripe’s hosted page; the card, the invoices and the cancellation of a Subscription are managed in Stripe’s billing portal, reached from Manage card and invoices in the application. The Provider holds no card data and no invoices; Stripe issues them on the Provider’s behalf. The Provider is the seller; Stripe is not the merchant of record. Stripe computes tax from what the Customer enters at checkout and collects VAT numbers there.

A Plan takes effect when Stripe confirms the payment. An abandoned checkout changes nothing. Buying any Plan ends the free month on that day and billing starts on that day; the plan picker says so and shows the days of the free month that were left.

A Subscription renews for the same period, monthly or yearly, until it is cancelled. An upgrade takes effect at once, and the difference is charged pro rata for the rest of the current period. A downgrade takes effect at the end of the paid period. A downgrade is scheduled; choosing the current Plan again cancels it; and while it is scheduled, new Agents and Accounts are counted against the Plan that is coming. Whether a change is an upgrade or a downgrade is decided by the monthly price, so that a change from yearly Solo to monthly Pro is an upgrade.

If the Workspace holds more Agents or Accounts than the coming Plan allows, the Customer must choose, before confirming the downgrade, which Agents and Accounts to switch off. They are switched off on the day the new Plan takes effect, marked as locked by the Plan, and release their slot. Switching one back on is refused until the Plan has room, and an upgrade does not switch them back on by itself. Jobs that would lose their last Agent are named before the Customer confirms.

Nothing else is taken away by a downgrade. Log text written under a longer window stays readable; run history is never removed by a Plan change; jobs remain unlimited; and a smaller output cap applies only to later runs.

A failed payment stops nothing at once. Stripe retries for a period and the Provider sends one email to the billing address. The Workspace is suspended only when the Subscription ends, whether because the retries failed or because the Customer cancelled. What happens then is in the section The life of a Workspace.

The Customer cancels a Subscription in Stripe’s billing portal. There is no cancel button in the application.

The Provider periodically compares its own records with Stripe’s view of the Subscription and corrects either direction: a Workspace running without a paid Subscription is suspended, and one suspended by mistake is resumed. Stripe’s view of the Subscription is decisive.

5.Acceptable use

The Customer may schedule only commands it may lawfully run, on machines it owns or is authorised to administer. The Software is installed by hand, so an Agent cannot be aimed at a machine its Customer does not control; these Terms make that fact a duty.

The Customer must not use the Service to attack, scan, spam or overload third parties or the Service; must not interfere with other Workspaces; must not circumvent limits, whether seats, Agents, rate limits or the free month; must not resell the Service; and must not remove notices from the Software, as Article 3 of the Licence says.

Studying, auditing, building and testing the Software’s source is permitted by Article 2 of the Licence, and nothing in these Terms prohibits it.

Each Workspace is its own database, and anything a Workspace has no access to is answered as not found. The Customer must not probe that boundary.

If the Customer breaches these Terms, the Provider may warn the Customer, suspend the Workspace, or delete it. Suspension and deletion follow the section The life of a Workspace, including the ability to export while suspended, wherever the law requires it.

6.Your content

The Customer owns its jobs, commands, schedules, tags, Agent names, and everything its runs print. The Provider claims no right in them beyond what the next paragraph grants.

The Customer grants the Provider the right to store, process, transmit to the Customer’s Agents, display in the application, and export this content, to the extent needed to provide the Service. The right ends when the content is purged.

The Customer warrants that its content is lawful and that it has the right to schedule the commands it schedules. The Customer answers for any personal data or secret its commands print into output, and for what it puts into job names, commands and Agent names. The Provider processes that content on the Customer’s instructions, as the GDPR notice at runjet.dev/gdpr describes.

7.Intellectual property

The Service, the application, the API, the documentation and the Software are the Provider’s. Runjet and the associated marks are the Provider’s marks, as Article 4 of the Licence says. These Terms grant the Customer the right to use the Service for as long as its Workspace exists, and nothing else; the right to run the Software is governed by the section The Agent and its Licence.

The Software is licensed under the Runjet Agent Licence, not under these Terms; the section The Agent and its Licence says how. The Software includes the Go standard library under its own notices, listed in Article 5 of the Licence.

The Customer may not copy, modify, redistribute or make derivative works of the Service or the Software except as the Licence permits.

8.Termination

The Customer ends the paid contract by cancelling the Subscription in Stripe’s billing portal. The Workspace is then suspended at the end of the paid period and follows the section The life of a Workspace. The Customer ends everything by asking for deletion by email to hello@runjet.dev; the Provider then deletes the Workspace as a support action.

The Provider ends the contract by suspending the Workspace for non-payment, which follows the same section, or by suspending or deleting the Workspace for breach of these Terms, for a security reason, or because the law requires it.

Suspension is not termination. Deletion is. A suspended Workspace stays readable and exportable; a deleted Workspace does not. The Software may be run for as long as the section The Agent and its Licence says.

Termination does not affect fees already due, the Customer’s warranties about its content, the section Liability, or the section Governing law and disputes.

9.Availability, support and disclaimers

The Provider offers no service level agreement, no uptime figure and no status page. The Service is provided with reasonable care and on a best-effort basis, including maintenance. It depends on Stripe for payments, on Cloudflare for serving the dashboard, on an email relay for every email it sends, and on a hosting provider for the API and the databases; none of these is under the Provider’s control.

Support is by email to hello@runjet.dev, answered by the one person who builds and runs the Service, usually within a business day or two, and without a guaranteed response time. On the Business Plan a report of anything that stops a job from running is handled first.

Notifications — a job failed or recovered, an Agent silent, a run running long, and the emails about the life of a Workspace — are sent on a best-effort basis. Delivery of email is not guaranteed, and the Customer must not rely on an email as its only signal that something is wrong.

The Provider does not promise that a job runs at a particular time or at all; the section The Service says why. Beyond what these Terms and mandatory law say, the Service is provided as it is and as it is available.

10.Liability

For a Customer who is not a consumer, the Provider’s aggregate liability for compensation of harm arising from the Service and the Software is limited to the greater of CZK 10,000 or the fees the Customer paid for the Service in the twelve months preceding the event that gave rise to the claim. This is the same cap as Article 7 of the Licence, so that the two documents cannot be played against each other. Changing it in one document changes it in the other.

The cap does not apply to harm caused intentionally or by gross negligence, to harm to a natural person’s natural rights, or to any other liability that mandatory law does not allow to be limited.

For a Customer who is a consumer, the Provider’s liability is limited only to the extent mandatory law allows.

The Provider is not liable for what a command does on the Customer’s machine, for a run that did not happen for any of the reasons in the section The Service, for the content of output, for third-party interference with the Customer’s hosts, or for the failure of a dependency named in the section Availability, support and disclaimers, except where the harm was caused by the Provider’s intent or gross negligence.

11.Changes to the Service and to these Terms

The API changes additively; the Software’s protocol is a version window that the Service serves, and an Agent outside it is refused until upgraded; the dashboard may change. The Provider may change the Service to improve it, to secure it, or to keep it working with its dependencies.

A change to the price list follows the section Plans, prices and payment.

12.Governing law and disputes

These Terms are governed by the law of the Czech Republic.

For a Customer who is not a consumer, any dispute arising from these Terms or the Service is decided by the Arbitration Court attached to the Czech Chamber of Commerce and the Agricultural Chamber of the Czech Republic, by one arbitrator, with its seat in Prague, in the Czech language, under that court’s rules. This is the forum Article 9 of the Licence chooses.

For a Customer who is a consumer, disputes are decided by the ordinary courts, and the consumer keeps the mandatory protection of the courts of their habitual residence. A consumer may also bring an out-of-court dispute to the Czech Trade Inspection Authority (Česká obchodní inspekce), coi.cz, which is the body for alternative resolution of consumer disputes in the Czech Republic; the Provider takes part in that procedure.

These Terms exist in English and in Czech, and the Czech text prevails, as the section Agreement says.

13.Contact

hello@runjet.dev is the one address for everything that matters: support, licensing, billing, a change of legal form, and a request for deletion. It is read by the person who builds and runs the Service and usually answered within a business day or two.

The imprint at runjet.dev/imprint says who operates the Service, their place of business, and the Company ID (IČO) the Provider can be looked up by in the public register.

14.Definitions

The Provider is Tomáš Jablonický, as described in the section Agreement. The Service is the hosted scheduler at runjet.dev, app.runjet.dev and api.runjet.dev, together with the documentation at docs.runjet.dev. The Software is the Runjet Agent, the program the Customer installs on its own machines, published at github.com/mr-jablon/runjet-agent. An Official Build is a binary of the Software published by the Provider in that repository, as the Licence defines it. The Licence is the Runjet Agent Licence, the files LICENSE and LICENSE-cz shipped with the version of the Software in use. The User is the Licence’s word for the person running the Software; under these Terms it means the Customer and everyone the Customer authorises.

The Customer is the party who registered the Workspace, in the declared legal form. A consumer is a Customer registered as an individual, and any Customer whom mandatory law treats as a consumer. A Workspace is the thing a Customer owns: one database, one billing address, and its jobs, Agents, Accounts, history and audit log, at app.runjet.dev/{workspace}. An Agent is one running instance of the Software enrolled in a Workspace; the Plan limit counts Agents, not machines, so one host running three Agents has used three. An Account is one person’s login inside a Workspace, with a role.

A Plan is Solo, Pro or Business, with the limits and price published in the price list. The free month, also called the trial, is the first thirty days of a Workspace, on the Pro Plan and without a card. A Subscription is the paid contract for a Plan, monthly or yearly, managed at Stripe. The price list is the prices and limits at runjet.dev/#pricing and in the plan picker at the moment of purchase. Suspended, deleted and purged are the states described in the section The life of a Workspace.

15.The Agent and its Licence

The Software is licensed to the Customer under the Runjet Agent Licence shipped with the version of the Software in use, in the files LICENSE and LICENSE-cz at github.com/mr-jablon/runjet-agent; the Czech text of the Licence prevails. The Licence is incorporated into these Terms by reference. The Licence governs the Software on the Customer’s machines; these Terms govern the hosted Service. Where the Licence permits running the Software solely for the purpose of using the Service in accordance with its terms, these Terms are the terms it means.

The Software is source-available and expressly not open source. Under Article 2 of the Licence the Customer may view, study, build and test the source in order to audit it; may download, install and run Official Builds, or unmodified binaries built from the published source, on its own devices for the purpose of using the Service; and may quote short excerpts. Under Article 3 the Customer may not redistribute, modify or make derivative works of the Software, use it outside the Service, distribute built binaries, or remove notices. The Software is provided as it is.

The Software runs as a system service, usually as root, and runs jobs under a separate account, runjet-job by default, so that a command cannot read the Software’s key or its secrets file; in the words of Article 6 of the Licence, that is a boundary, not a sandbox. The Customer must install it as docs.runjet.dev describes, run it with least privilege, secure the host, and install updates without undue delay. The Software enforces no Plan limit; the Service does.

The Customer’s right to run the Software lasts while the Customer has an active relationship with the Service under Article 8 of the Licence. The relationship ends on the events Article 8 of the Licence names: the free month ending without a move to a paid Plan, the Subscription ending, whether the Customer cancelled it or it ended for non-payment, or the Workspace being deleted. Each of these is also the day the Workspace is suspended or deleted, as the section The life of a Workspace describes. From that day the Customer must, without undue delay and within thirty days at the latest, stop running the Software and remove it from all of its devices; for a suspended Workspace that period coincides with the thirty days before it is deleted. The Agents of a suspended Workspace keep reporting in meanwhile and receive nothing; that is how the Service behaves, not an extension of the Licence. If the Customer pays while the Workspace is suspended, a new active relationship begins and with it the right to run the Software again, so the Software need not be removed and installed again.

The Provider may revoke the Licence with thirty days’ notice by publication in the repository, without affecting a running Subscription. If the Provider does so, a Customer with a paid Subscription keeps the right to run the Software for the paid period, or receives a pro-rata refund of the unused part.

A new Licence applies to future versions of the Software; a version already downloaded keeps the Licence of its release. An Agent whose protocol version falls outside the window the Service serves is refused until upgraded, as the section The Service says. The Software and the Service are upgraded by different people on different days; the Agent list marks an Agent speaking an older protocol version, but no notice period before the window moves is promised.

16.The free month

Every new Workspace starts on the Pro Plan for thirty days from registration, without a card and with the full Pro limits. No card, no setup fee, no minimum term. The Plan is chosen at the subscribe step, never at registration.

Buying any Plan ends the free month on that day, and billing starts on that day. The plan picker says so and shows the days that were left. A Customer who buys before day thirty gives up the days that were left.

The Provider emails the billing address to say that the free month is coming to an end; the emails are scheduled for day 25 and day 28. It is not promised that both arrive: if the Service was down, only the most urgent is sent when it returns. On day 30 without a payment the Workspace is suspended and follows the section The life of a Workspace.

17.The life of a Workspace

The numbers in this section are the same as on runjet.dev, at docs.runjet.dev/workspace/lifecycle and in the emails the Service sends. The periods are commitments, not configuration; the emails that warn of them are scheduled, but their delivery is not promised, as the paragraphs below say.

A Workspace is suspended on day thirty of the free month without a payment, or on the day a Subscription ends, whether because it was cancelled or because the payment provider gave up. In a suspended Workspace scheduling stops and nothing runs; running a job by hand is refused; every change is refused with HTTP 402 and the sentence this workspace is suspended — subscribe to make changes again; everything stays readable, including jobs, Agents, history and outputs; Agents keep reporting in and receive nothing; and export works. Paying resumes the Workspace at once with everything as it was. The occurrences missed while suspended are not run.

From the day of suspension the Provider emails the billing address to say that deletion is approaching; the emails are scheduled for day 15, day 25 and day 28, and each states the days remaining, counted to the real day of deletion. It is not promised that all of them arrive: if the Service was down, only the most urgent of those that fell due meanwhile is sent when it returns. The last of them says to export while the Workspace is still readable. On day 30 after suspension the Workspace is deleted: the database is set aside, the address stops answering, nothing signs in, Agents cannot reach it, and export is no longer possible. Every byte still exists. A final email says that a reply within thirty days brings the Workspace back.

Thirty days after deletion the Workspace is purged: the database is dropped. Purge is irreversible.

The Customer may ask for immediate deletion at any time by email to hello@runjet.dev; the Provider then deletes the Workspace as a support action, and purge follows thirty days later. The two thirty-day windows are a safety delay so that no unattended process decides about the Customer’s data from date arithmetic alone; they are not a retention right the Provider claims. The Privacy Policy and the GDPR notice give the same periods.

A notification is sent once its number of days has passed and it has not yet been sent; an email may be late, never doubled. If the Service was down, only the most urgent of the thresholds that fell due meanwhile is sent when it returns, and the rest are treated as dealt with. The notifications tied to suspension are cleared when a Workspace resumes, so a Customer who lapses a second time is warned again; the ones about the end of the free month are not cleared, because the free month happens once. Every email in this section goes to the billing address. They are part of the Service and not marketing, and they cannot be opted out of while the Workspace exists.

18.Export, data and retention

An admin can export the Workspace. The export is one zip archive holding every job with its schedule, tags and secret names; the whole run history, including the outputs not yet swept; the Agents with their names, versions and enrolment state; the Accounts and their roles; and the audit log. It does not hold the values of secrets, because the Service never had them, nor the Agents’ keys. The archive is built outside the request; its link lasts one hour and works once; every export is recorded in the audit log. Export works while the Workspace is suspended and is impossible after deletion. The archive holds whatever the Customer’s commands printed and is as sensitive as the Account that made it.

Retention is as follows. Run rows — status, timings and outcome — are kept for as long as the Workspace exists, on every Plan. Output text is kept for the Plan’s window, swept periodically and replaced by a marker saying the output is no longer kept; the sweep never reaches past the window under which the text was written. Output beyond the Plan’s per-run cap is cut and a marker left. The audit log is never swept. Export files are removed a few hours after their link expires. The Workspace’s data is deleted and purged as the section The life of a Workspace says.

As controller, the Provider processes the personal data the Service needs: Account emails and names, password hashes, sessions, IP addresses in the audit log and at signup, the declared legal form and registration number, the billing email, and the emails sent. Stripe holds payment details, billing address and VAT number. As processor on the Customer’s instructions, the Provider processes whatever the Customer puts into job names, commands and Agent names, and whatever the Customer’s runs print. The Privacy Policy at runjet.dev/privacy describes the handling of personal data briefly and for a reader who has not decided yet; the GDPR notice at runjet.dev/gdpr sets out legal bases, rights, transfers and sub-processors, and carries the processing agreement. For a Customer who is not a consumer, the data processing agreement in the GDPR notice is part of the contract.

The Provider can read a Workspace’s data to provide support the Customer asked for, or to investigate abuse or a security incident.

19.Consumer provisions

This section applies to a Customer registered as an individual, and to any Customer whom mandatory law treats as a consumer regardless of the declaration. Where it differs from the rest of these Terms, this section prevails for that Customer.

Before a consumer buys a Plan the Provider makes available: the Provider’s identity and address (the section Agreement and the imprint at runjet.dev/imprint); the price of each Plan and whether it includes taxes (the price list and the checkout); the duration of the Subscription and how it renews and ends (the sections Plans, prices and payment, Termination and The life of a Workspace); the functionality, compatibility and interoperability of the Service and the Software (the sections The Service and The Agent and its Licence, and docs.runjet.dev); the right of withdrawal (this section); and the handling of complaints and the supervisory authority (this section and the section Governing law and disputes).

A consumer may withdraw from the paid contract within fourteen days of buying a Plan, without giving a reason, by email to hello@runjet.dev. Because billing starts on the day of purchase, the checkout asks the consumer to expressly request that the Service begin at once and to acknowledge that, on withdrawal, they pay a proportionate part of the price for the period before withdrawal. The refund of the rest is a manual action in Stripe, made within fourteen days of the withdrawal.

The Service must conform to the contract: it must make due jobs available to the consumer’s Agents and record what they report, as the section The Service describes, and it must keep the behaviour described there and in the documentation. The Service does not execute commands, and conformity does not extend to what a command does or to whether it runs on the consumer’s machine. Updates of the Software on the consumer’s machines are the consumer’s own action; the Provider publishes them and marks, in the Agent list, an Agent speaking an older protocol version than the Service serves. If the Provider modifies the Service in a way that has a more than minor negative impact on the consumer, the Provider informs the consumer in advance, and the consumer may terminate within thirty days of the modification without cost.

The Provider handles complaints sent by email to hello@runjet.dev and answers them within thirty days. The supervisory authority is the Czech Trade Inspection Authority (Česká obchodní inspekce), which is also the body for out-of-court resolution of consumer disputes, at coi.cz.