Every invocation, seen.
No host to patch, and no host to bill.
Datadog Serverless Monitoring covers AWS Lambda, Azure Functions, Azure App Service, Azure Container Apps and Google Cloud Run, with traces, enhanced metrics and logs from inside the function. We implement it through your deployment tooling, scope which functions count, and run it every month so the active function count on the invoice is a number you chose.
Quick facts
Related
- APM, the trace that passes through the function
- Infrastructure Monitoring, the hosts the functions call
- Log Management, where the function logs land
The function that timed out, with the reason attached
A Lambda times out at thirty seconds, once every few hundred invocations. CloudWatch has the log line that says it timed out. It does not have the downstream call that took twenty-nine of those seconds, or the cold start that took the other one. Serverless Monitoring puts the whole invocation on one trace.
One trace per invocation. The Extension and the Serverless Agent run alongside the function and send the trace from inside it, joined to the API Gateway, queue or event that triggered it and to the services it called.
Metrics the platform does not give you. Enhanced metrics for cold starts, estimated cost, memory used against memory allocated, errors by type and, for queue-driven functions, how far behind the stream they are.
Logs without the relay. The Extension ships function logs directly, tagged with the same service and version as the trace, so the log line and the span that wrote it are one click apart.
The same view across three clouds. Lambda, Azure Functions, App Service, Container Apps and Cloud Run appear in the same Serverless view, under the same tags, with the same monitors, instead of three consoles and three alerting tools.
A tag filter nobody set, a log shipped twice, and a function that counts once per region
How it bills. There is no host meter for functions. Lambda is billed on active functions: every hour Datadog counts the functions that ran at least once and were monitored, then averages the hourly counts across the month. A function is identified by its ARN, so a Lambda@Edge function counts once per region. Tracing is billed per million traced invocations, with indexed spans beyond the bundle on the APM span meter. Each billable function carries a custom metric allotment. Azure Functions, App Service, Container Apps and Cloud Run are billed per active application instance, counted in five-minute intervals and averaged across the month, and tracing on those per actively traced instance. The one host meter that does apply is Azure's: the Azure integration counts the nodes inside App Service plans as Infrastructure hosts, except on the Shared, Dynamic and Free tiers. A function instrumented with the Extension is billable even when the AWS integration is switched off. Datadog publishes the rates. We publish nothing here, because the price is not the problem. The configuration is.
The configuration traps. The AWS integration tile, left at its default, monitors every Lambda in every connected account, and a function that runs once an hour to rotate a key is an active function every hour. The Forwarder was set up during the trial and the Extension was added at the rollout, so the same log line arrives twice. The Extension version is pinned in each function's deployment config by hand, in a different repository each time. Tracing on the busiest function at full sampling fills the indexed span bundle by the second week. None of this raises an alert. All of it reaches the invoice.
Field noteThe most common surprise we see is the housekeeping functions. Scheduled cleanups, key rotations, cache warmers and health pings each run every few minutes, each is an active function in every hour of the month, and together they outnumber the functions that serve customers.
Field noteThe Forwarder was never removed when the Extension went in. Every function log arrives from CloudWatch and from the Extension, with slightly different tags, so the duplicates are not obvious in the explorer. The log volume for the account is double what the functions write.
Field noteA Lambda@Edge function deployed to a CloudFront distribution is replicated to every region the distribution serves from. The function count in Datadog is a multiple of the function count in the repository, and the first explanation offered is a billing error.
Field noteThe Extension layer version was set per function, by hand, when each function was first deployed. Years later the fleet runs a spread of versions, and the enhanced metrics the dashboards assume exist only on the functions deployed most recently.
Filters first. Instrumentation through the pipeline. One log path per function.
A new rollout starts with LaunchPad, which runs the implementation as a managed project with a named engineer and a written scope. If the cloud integrations are already connected, a Datadog HealthScan comes first. It is read-only and fully automated, and it reports active function counts, Extension versions and duplicate log sources before we change anything. Either way, the sequence is the same.
- Inventory the functions, per account and per platform. Every Lambda, Azure Function, App Service, Container App and Cloud Run service, with its runtime and trigger. Each is marked as serving a customer or the platform.
- Decide which functions are monitored. Tag filters on the integration tiles so that housekeeping functions are excluded by default and product functions are included by default. Written down, with the reason.
- Standardise the instrumentation in the deployment tooling. Extension, compatibility layer or Serverless Agent, with the version pinned once in the shared module rather than once per function.
- Set unified service tags and trace sampling. env, service and version on every function. Sampling per function from its traffic, so the traced invocation volume and the indexed span bundle are decided rather than discovered.
- Choose one log path per function and build the monitors. Extension or Forwarder, never both. Then errors, throttles, duration at the tail, cold starts and iterator age, with thresholds from a fortnight of real data.
- Hand over, in writing. Which functions are monitored and which are filtered, and which instrumentation each platform uses. Plus the active function and instance counts on the day we finished.
Access is admin on the Datadog organisation plus read access to the cloud accounts and the deployment repositories. Instrumentation changes go through your pipeline, not ours. We do not need deploy rights on production functions to implement Serverless Monitoring, and we do not ask for them.
Functions are cheap to create. That is the whole problem.
A new function ships without the tag that would have excluded it. A trigger changes from hourly to every minute. An Extension version is bumped in one module and not the other. Managed Observability is the monthly service that keeps Serverless Monitoring matching the functions it watches.
Every month, we review the meters. Active function and active instance counts against last month, traced invocations against the sampling decisions, log volume per function against the single-path rule. Anything that moved gets a reason or a fix.
Coverage follows the deployments. A function that shipped last month without tags, or with tracing left at full sampling, is found in the review and corrected before it is the function everyone is looking for.
Monitors earn their place. A monitor that has not fired for a real reason in a quarter is retired or rebuilt. Alert noise is a configuration problem, and configuration is what we run.
The incident is ours to take. Under Critical Support our engineers answer the page the function raised, 24x7, and fix the cause rather than report it. Datadog has published that our work reduces mean time to resolve incidents by 40 to 60 per cent.
We operate the stack. You own the product.
An implementation partner adds the Extension and hands over. A managed partner is still there when a new account is connected in March and two hundred housekeeping functions join the meter. We are the second kind. The integration filters, the shared instrumentation module and the decisions behind them stay in your repositories and your Datadog organisation, documented, and you can take them in-house whenever you choose.
Datadog is our proof, not our headline. Datadog certified one managed provider globally. We are it. The Powered by Datadog accreditation means Datadog's own engineers reviewed how we instrument, alert, respond and report. We are also a Datadog Advanced Partner, ISO 27001 certified and Cyber Essentials Plus certified, with offices in Cardiff, London and Dublin.
Datadog Serverless Monitoring, answered plainly
How is Datadog Serverless Monitoring billed?
There is no host meter for functions. For AWS Lambda the meter is active functions: every hour Datadog counts the functions that ran at least once and were monitored, and bills on the average of those hourly counts across the month. A function is identified by its ARN, so a Lambda@Edge function counts once per region it runs in. Tracing is billed per million traced invocations, with indexed spans beyond the bundled amount billed on the APM span meter. Each billable function carries an allotment of custom metrics. Azure Functions, Azure App Service, Azure Container Apps and Google Cloud Run are billed per active application instance, counted in five-minute intervals and averaged across the month, and tracing on those per actively traced instance. The Azure integration also counts the nodes inside App Service plans as Infrastructure hosts, except on the Shared, Dynamic and Free tiers. We do not publish prices. The meters are what we tune.
Should we use the Datadog Lambda Extension or the Forwarder?
For new rollouts, the Extension. It runs alongside the function, sends traces, enhanced metrics and logs directly, and does not need a separate Lambda in the account to relay them. The Forwarder still has a job: it ships logs from CloudWatch for functions you cannot or do not want to instrument, and it handles other AWS log sources. Running both on the same function sends the same logs twice, and the log meter counts both copies. Choosing one per function is part of the implementation.
Does Datadog Serverless Monitoring cover Azure Functions and Google Cloud Run?
Yes. Azure Functions are instrumented with the Datadog .NET APM extension for .NET on Windows on the Premium and Dedicated plans, and with the Serverless Compatibility Layer for everything else, including the Consumption and Flex Consumption plans. Azure App Service has its own extension. Azure Container Apps and Google Cloud Run, including Cloud Run functions, use the Serverless Agent, which runs alongside the application and collects traces, enhanced metrics, custom metrics and logs directly. The Azure and Google Cloud integrations add the platform metrics and logs on top.
Do we need the Datadog Agent for serverless?
Not the host Agent, because there is no host. On Lambda, the Extension does the Agent's job inside the execution environment. On Cloud Run and Container Apps, the Serverless Agent does. On Azure Functions and App Service, the extension or the compatibility layer does. The cloud integration fills in whatever the platform exposes about the function from outside. What you do need is for the instrumentation to arrive through the deployment tooling rather than by hand, because a function that was instrumented once by hand is a function that drifts.
What does Critical Cloud do with Serverless Monitoring every month?
Managed Observability runs it. Every month we review the active function count and the active instance count against the previous month, check the integration tag filters against the functions that exist now, confirm the Extension and Serverless Agent versions are current across the deployment tooling, review traced invocation volume and the log scope, retire monitors that no longer fire for a real reason, and report what changed. Under Critical Support our engineers also take the page when a function goes wrong, 24x7.
- Datadog products: every product, and how we implement and run each one
- Datadog APM: the trace the function is one span of
- Datadog Log Management: the meters the function logs land on
- Infrastructure Observability Accelerator: infrastructure, APM and logs operational in four weeks
Every invocation explained. A function count you chose.
Tell us how many functions you think you run. We will tell you how many Datadog is counting, why the two differ, and what it takes to make the traces explain the timeouts.