Two Ways to Trigger a Serverless Function: Cron Jobs and HTTP Requests Explained

Serverless functions are event-driven by nature. They don't run continuously like a long-lived server process — they execute in response to something that happened. Understanding what triggers them is the foundation of serverless architecture.

On moqapi.dev, there are two primary ways to invoke a function: a scheduled cron trigger and a live HTTP request. This guide explains both mechanisms in depth, with real code examples, common use cases, and a comparison to the equivalent patterns in AWS Lambda and Azure Functions.

Trigger Type 1: HTTP Requests

An HTTP-triggered function is the serverless equivalent of a REST API endpoint. Every time a client sends an HTTP request to the function's URL, moqapi.dev executes your handler and returns the response.

How It Works

When you deploy a function on moqapi.dev, it receives a unique HTTPS endpoint:

https://moqapi.dev/invoke/{projectId}/{functionName}

Any HTTP method is supported — GET, POST, PUT, DELETE, PATCH. Your handler receives the full request object including headers, query parameters, and body.

Example: A Minimal HTTP Handler (Node.js)

export default async function handler(req, res) {
  const { name } = req.body;

  if (!name) {
    return res.status(400).json({ error: "name is required" });
  }

  const greeting = `Hello, ${name}! Triggered at ${new Date().toISOString()}`;

  return res.status(200).json({ message: greeting });
}

Calling this function is as simple as:

curl -X POST https://moqapi.dev/invoke/your-project/greet   -H "Content-Type: application/json"   -d '{"name": "Alice"}'

Common HTTP Trigger Use Cases

• REST API backends — serve JSON data to a frontend application.
• Webhook receivers — listen for Stripe payments, GitHub push events, or Slack slash commands.
• Form handlers — process contact form submissions without a backend server.
• Proxy functions — forward requests to third-party services while adding auth headers.
• Real-time data endpoints — aggregate data from multiple sources and return a unified response.

Authentication on HTTP Triggers

By default, moqapi.dev function endpoints require a project API key in the Authorization header. You can also configure public endpoints for webhooks that must accept requests without credentials.

curl -X POST https://moqapi.dev/invoke/your-project/your-function   -H "Authorization: Bearer YOUR_API_KEY"   -H "Content-Type: application/json"   -d '{"event": "payment.completed", "amount": 4900}'

How This Compares to AWS Lambda HTTP Triggers

In Lambda, HTTP triggers require an API Gateway — a separate service that maps HTTP routes to Lambda function ARNs. You configure this through the console or CloudFormation, and it adds latency (API Gateway has its own cold-start footprint) plus separate billing at $3.50 per million requests.

On moqapi.dev, the HTTP endpoint is built into every function. No API Gateway. No separate service. No additional cost per request.

Trigger Type 2: Cron Jobs (Scheduled Execution)

A cron-triggered function runs on a schedule — every minute, hourly, daily, or on any custom cron expression. There's no incoming HTTP request; the platform itself fires the function at the specified time.

How It Works

In your moqapi.dev dashboard, navigate to Cron Jobs, create a new job, attach it to any deployed function, and set a cron expression. The platform handles scheduling, retries on failure, and execution logs.

Cron Expression Syntax

moqapi.dev uses standard 5-field cron syntax:

┌─────── minute (0–59)
│ ┌───── hour (0–23)
│ │ ┌─── day of month (1–31)
│ │ │ ┌─ month (1–12)
│ │ │ │ ┌ day of week (0–6, 0=Sunday)
│ │ │ │ │
* * * * *

Examples:

• 0 * * * * — every hour at minute 0.
• 30 6 * * 1-5 — 6:30 AM Monday through Friday.
• */15 * * * * — every 15 minutes.
• 0 0 1 * * — midnight on the first day of every month.

Example: A Daily Report Function

export default async function handler(req, res) {
  // This function is called by the cron scheduler — req.body.trigger === 'CRON'
  const today = new Date().toISOString().slice(0, 10);

  // Query your database for yesterday's metrics
  const metrics = await fetchDailyMetrics(today);

  // Send a summary to Slack
  await fetch(process.env.SLACK_WEBHOOK_URL, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      text: `Daily report for ${today}: ${metrics.totalRequests} requests, ${metrics.errorRate}% error rate`,
    }),
  });

  return res.status(200).json({ status: "report sent", date: today });
}

Set the cron expression to 0 8 * * * and this function fires every morning at 8 AM, with no server to keep running overnight.

Common Cron Trigger Use Cases

• Daily/weekly report generation — email or Slack summaries of business metrics.
• Database cleanup jobs — delete soft-deleted records older than 30 days.
• Cache warming — pre-compute expensive queries before business hours start.
• Subscription renewals — check expiring trials and send automated reminder emails.
• Health checks — ping downstream APIs and alert if they're down.
• Data synchronisation — pull data from a third-party API every hour and write it to your database.

How This Compares to AWS Lambda Cron Triggers

In AWS, scheduled Lambda execution requires Amazon EventBridge (formerly CloudWatch Events). You create an EventBridge rule with a cron or rate expression, point it at a Lambda ARN, and grant the rule permissions to invoke the function.

That's three services (Lambda + EventBridge + IAM) to do what moqapi.dev's Cron Jobs page does in 30 seconds.

Azure Functions uses either a Timer Trigger binding in the function code itself, or Azure Logic Apps for more complex schedules — both requiring Azure-specific configuration that doesn't transfer to other platforms.

Combining Both Triggers: The Hybrid Pattern

The most powerful serverless architectures combine both trigger types. A common pattern:

1. A cron job fires every hour, queries recent data, and publishes a snapshot to a shared endpoint.
2. An HTTP endpoint serves that snapshot to frontend clients, with sub-10 ms response times because the heavy computation already happened.

This separates computation (scheduled, background) from serving (on-demand, real-time) — a pattern that scales well and keeps both functions simple.

Monitoring Triggered Functions

Every execution on moqapi.dev — whether triggered by HTTP or cron — appears in the Logs dashboard with:

• Trigger source (HTTP or CRON).
• Execution status (Success or Error).
• Duration in milliseconds.
• Function output and any console logs from inside the handler.

Failed cron executions are surfaced immediately — no CloudWatch query required.

Quick-Start Checklist

To set up both trigger types on moqapi.dev:

1. HTTP trigger: Create a function → write your handler → deploy → copy the endpoint URL → call it from curl, Postman, or your frontend.
2. Cron trigger: Create a function → deploy → go to Cron Jobs → New Job → select your function → enter a cron expression → save.

Both are live in under five minutes, with no infrastructure to manage, no IAM policies, and no YAML configuration files.

Start building at moqapi.dev/signup — the free tier includes HTTP-triggered functions and scheduled cron jobs.