---
title: Web services, workers and cron jobs
description: Choose how a service runs, as a web service on a port, a worker in the background, or a cron job on a UTC schedule.
section: Services
order: 3
---

Every service has a **Runs as** setting that you choose when you add it. A web service listens on a port and gets an HTTPS address, a worker runs continuously without a port, and a cron job starts on a schedule, runs to completion and stops until the next run.

| Runs as | Port and address | Start command | Counts as an active service |
| --- | --- | --- | --- |
| Web service | Yes, with an address on `apps.dekka.cloud` | Optional | Yes |
| Worker | No | Required | Yes |
| Cron job | No | Required | No |

In the API these are the resource kinds `application`, `worker` and `scheduled_job`. All three build and deploy the same way, from GitHub or an image, and all three can connect to databases and buckets.

## Run a web service

A web service must listen on `0.0.0.0` on its port, which Dekka also passes to it as `PORT`. Dekka sends traffic to a new release only after its health check path returns a 2xx, and it is the only kind that can have [custom domains](/docs/domains) and [HTTP request logs](/docs/logs#read-http-request-logs).

## Run a worker

Choose **Worker** for queue consumers and other processes that run without serving HTTP, and give it a start command such as `node worker.js` or `celery -A app worker`. A worker is restarted according to its [restart policy](/docs/build-configuration#what-happens-when-my-service-crashes).

## Schedule a cron job

Choose **Cron job**, give it a start command and a schedule in five fields: minute, hour, day of month, month and day of week. Schedules run in UTC, and Ghana keeps UTC all year, so `0 2 * * *` runs at 02:00 in Accra every day.

| Schedule | Runs |
| --- | --- |
| `*/15 * * * *` | Every 15 minutes |
| `0 2 * * *` | 02:00 every day |
| `30 8 * * MON-FRI` | 08:30 on weekdays |
| `0 0 1 * *` | Midnight on the first of each month |

Each field takes `*`, a number, a range such as `1-5`, a step such as `*/10` or `0-30/5`, and lists separated by commas. Months accept `JAN` to `DEC`, and days of the week accept `SUN` to `SAT`, where `0` and `7` both mean Sunday. When both the day of month and the day of week are restricted, a day matches if either one does. The dashboard describes a schedule in words as you type it, the API returns the next five run times as `next_runs`, and Dekka refuses a schedule that can never run, such as `0 0 31 2 *`.

## See and start cron job runs

Select a cron job on the canvas and open **Runs** to see each run with its status, exit code and output, newest first. **Run now** starts one straight away with the job's start command. A run moves from `queued` to `running` and ends `succeeded`, `failed` or `cancelled`, and a scheduled time that arrives while the previous run is still going is recorded as `skipped` rather than starting a second copy.

```bash tab="cURL"
curl -X POST https://api.dekka.cloud/v1/resources/$JOB_ID/runs \
  -H "Authorization: Bearer $DEKKA_API_KEY"
```

A job that hasn't been deployed yet answers 409 `job_not_deployed`, and one whose last run is still going answers 409 `run_in_progress`.

## Change how a service runs

Setting a cron schedule in a worker's or web service's settings turns it into a cron job, and clearing the schedule turns it back into a web service if it has a port or a worker if it doesn't. A web service with custom domains has to lose them before it can become a cron job.