# Functions overview

Source: https://cloud.synteq.com/docs/functions-overview
Updated: 2026-10-19T04:06:19.693440+00:00

---
# Functions overview

A function is a Node.js or Python handler that runs on each HTTPS request.

Functions suit webhook receivers, small APIs, scheduled jobs, and glue code between services. For something that runs continuously, such as a web server or a background worker, use an app or VPS.

## Key features

- **Runtimes**: Node.js 22 and Python 3.12, or your own Dockerfile.
- **Deploys**: from the browser editor, a GitHub folder, or the `synteq` CLI.
- **Address**: an HTTPS subdomain on `fn.synteq.app`, plus custom domains.
- **Scaling**: instances start on the first request and stop after an idle period.
- **Cron triggers**: run the function on a UTC schedule.
- **Billing**: per run, and on some plans per GB-second.
- **Monthly budget**: an optional cap on runs per month.

Functions live inside a project. Creating or changing a function needs the Technical role, owner, or admin. Read-only members can view functions, logs, and usage.

## Your function's address

Every function gets its own HTTPS address as soon as it's created:

```
https://<name>.fn.synteq.app

```

The name becomes the subdomain, so it uses lowercase letters, numbers, and hyphens, up to 63 characters. It can't start or end with a hyphen, and it must be unique across Synteq. Custom domains are added from the **Domains** tab.

## How a function runs

### Starting up and going idle

When a request arrives and no instance is running, Synteq starts one. The request waits while it boots; this is a cold start. Node.js and Python handlers start from a pool of runtimes that is already booted, so a cold start is the time to load your handler. In most cases, declared dependencies are part of that pool and add nothing. Typical cold starts, measured inside the Dallas datacenter:

| Runtime | Typical cold start |
| --- | --- |
| Node.js | about 100 ms |
| Python | about 100 ms |
| Your own Dockerfile or server | 1–2 seconds, depending on how long your image takes to start listening |

A handler that loads a large native module (an image library, for example) adds that module's load time to its cold start. A running instance adds 10–20 ms of platform overhead per request inside the datacenter. It stops after 90 seconds without requests, and the next request starts a new one.

Traffic that arrives in bursts with long gaps pays a cold start at the start of each burst.

### Handling more traffic

Each instance serves up to **Concurrency** requests at once, 10 by default. When every instance is busy, Synteq starts another, up to **Max instances**, 5 by default.

At the defaults a function serves 50 requests at once. Requests beyond that wait for a free slot rather than fail, so latency rises. Raise **Max instances** if this happens regularly. Requests also queue while instances start, and a very large burst can get a `503`.

Handlers that mostly wait on I/O work well at a Concurrency of 10 or more. For CPU-bound handlers, lower it so requests spread across more instances.

### Isolation

Each instance is a separate microVM with its own kernel, memory, and filesystem. Nothing is shared with other customers or with your function's other instances.

Instances start and stop as traffic changes, and consecutive requests can land on different instances. Keep state in a database or other external store, not in memory or on local disk.

### Timeouts and errors

A request runs for up to 30 seconds by default. The **Timeout** in **Settings** goes up to 5 minutes. A request that exceeds it returns `504` and is logged as timed out.

An uncaught error in your handler returns `500`, and the error appears in the run's logs. If no instance is ready within 30 seconds, the request returns `504`; it never reached your code and isn't billed.

## Statuses

| Status | What it means |
| --- | --- |
| **Provisioning** | The function is being created, usually for a few seconds. |
| **Active** | The function serves requests, including while no instances are running. |
| **Paused** | Requests return `429`. The banner on the function gives the reason. |
| **Deleting** | The function is being removed. |
| **Failed** | Creation failed. Open a support ticket. |

The dot next to the status reflects most runs over the last 30 minutes, or the latest run when there were none in that window: green for success, red for an error or timeout.

## Memory and CPU

The runtime size sets each instance's memory. CPU scales with memory. The size also sets the maximums for Concurrency, Timeout, and Max instances. Some plans fix the size.

## Billing

### Runs

A run is one request that reaches your handler, whatever the result. Successes, errors, and timeouts each count as one run, as do cron runs and runs started with **Trigger now**.

Requests that never reach your handler are not runs: the `429` from a paused function and the `504` when no instance is ready in time.

### GB-seconds

Some plans also bill compute in GB-seconds: instance running time multiplied by memory in GB. One 512 MB instance running for a minute uses 30 GB-seconds.

Compute is measured for as long as an instance runs, including the 90 seconds before an idle instance stops, not per request.

### Plans

Plans are chosen on the **Billing** tab. Your organization's catalog can include:

| Plan | How it works |
| --- | --- |
| **Free** | A monthly allowance of runs at no charge. |
| **Included runs plus overage** | A monthly price that includes a number of runs, with a per-run rate for anything over. |
| **Choose your runs** | A monthly run quantity you choose, with overage beyond it. |
| **Prepaid credits** | Runs bought in advance; each run uses one credit. |
| **Unlimited** | A flat monthly price with no run counting. |

Every plan, including Free, needs a payment method on the organization. Usage resets monthly on the day the function was created.

Some organizations use a shared credit pool instead of per-function plans. The Functions list then shows a team credits balance, and functions have no **Billing** tab of their own.

### When you reach your plan's limit

The plan either fixes what happens when included runs run out, or lets you choose under **Settings** → **Spend**:

| Option | Description |
| --- | --- |
| **Pause until the next period** | The function stops serving until the month resets or the plan changes. |
| **Bill the overage** | The function keeps serving and extra runs are billed. |
| **Upgrade the plan automatically** | The function moves to the next plan and keeps serving. |

The **Billing** tab shows which applies. Changing plan clears the choice.

## Monthly budget

**Monthly budget** under **Settings** → **Spend** caps runs per month. At the cap the function pauses and your team is notified. Leave it empty for no cap.

A paused function returns `429`. Deploys still work and go live on resume. The banner shows why when the pause came from your budget or plan:

| Reason | How to resume |
| --- | --- |
| **Monthly budget reached** | Raise or clear the budget and save, or wait for the next month. |
| **Plan run allowance used up** | Change plan, or wait for the next month. |
| **This function is paused** | If you paused it, click **Resume function** under **Settings** → **Danger zone**. Otherwise, open a support ticket. |

To delete a function, pause it first. Deleting becomes available after 14 days paused.

## In the portal

Functions appear under their project in the sidebar, in the Cloud section. The list shows each function's name and address, its latest deploy with when and by whom, its runs over the last 30 days, and its health.

| Tab | What's there |
| --- | --- |
| **Overview** | Code editor and deploy button. |
| **Logs** | Each run with its output, status, and duration. |
| **Versions** | Every deploy, with compare and roll back. |
| **Environment** | Environment variables and secrets. |
| **Triggers** | Cron schedules and **Trigger now**. |
| **Domains** | The `fn.synteq.app` address and custom domains. |
| **Billing** | Plan, usage this month, and billing history. |
| **Settings** | Source, execution settings, spend controls, and delete. |
| **Activity** | Who changed what, and when. |

The `synteq function` commands in the CLI cover the same operations.

## Limits

| Item | Limit |
| --- | --- |
| Function name | 1–63 characters: lowercase letters, numbers, hyphens; no hyphen at the start or end |
| Source size | 32 files and 900 KB total in the editor; up to 5 MB from the CLI or GitHub |
| Concurrency | 1–100 (default 10) |
| Timeout | 1 second to 5 minutes (default 30 seconds) |
| Max instances | Default 5; the upper limit depends on the runtime size |
| Cron triggers | 10 per function, schedules in UTC |
| Log output kept per run | 500 lines |

## What next?

- Writing and deploying a function: the handler format and the three ways to deploy.
- Triggers, operations, and billing: cron, logs, rollback, custom domains, and the Billing tab.
- Getting started with the CLI: install, log in, and deploy from a terminal.