Eventarc overview

Eventarc allows you to build event-driven architectures without having to implement, customize, or maintain the underlying infrastructure. It offers a standardized solution to manage the flow of state changes, called events, between decoupled microservices. Eventarc routes these events to Cloud Run while managing delivery, security, authorization, observability, and error-handling for you.

Eventarc architecture

You can manage Eventarc from the Google Cloud Console (using Cloud Run), from the command line using the Cloud SDK, or by using the Eventarc API.

Key use cases

Eventarc supports many use cases for applications running on Cloud Run. Some examples:

Configure and monitor
  • System configuration—Install a configuration management tool on a new VM as soon as it is started.
  • Automated remediation—Detect if a service is not responding properly and automatically restart it.
  • Alerts and notifications—Monitor the balance of a cryptocurrency wallet address and trigger notifications.
  • Directory registrations—Activate an employee badge as soon as a new employee joins a company.
  • Data synchronization—Trigger an accounting workflow when a prospect is converted in a CRM system.
  • Resource labeling—Label and identify the creator of a VM when it is created.
  • Sentiment analysis—Use the Cloud Natural Language API to train and deploy an ML model that attaches a satisfaction score to a customer service ticket as soon as it is completed.
  • Image retouching and analysis—Remove the background and automatically categorize an image when a retailer adds it to an object store.


An event is a data record expressing an occurrence and its context. An event is a discrete unit of communication, independent of other events. For example, an event might be a change to data in a database, a file added to a storage system, or a scheduled job.

For a list of the events supported by Eventarc, see Events supported by Eventarc.

Event sources

Events are routed from an event producer (the source) to interested event consumers. The routing is performed based on information contained in the event, but an event does not identify a specific routing destination. Currently, Eventarc supports events from the following sources:

  • More than 90 Google Cloud sources. Events from these sources are either sent directly (Cloud Storage) or through Cloud Audit Logs entries, and use Events Core and Pub/Sub as the transport layer.
  • Custom sources. Events from custom applications use Pub/Sub to send event notification messages.

To determine how best to route events to a Cloud Run service, see Event routing options.

Event targets

Events are routed to a specific destination (the target) known as the event receiver (or consumer). Currently, Cloud Run is Eventarc's only event receiver. Learn how to build an event receiver service that can be deployed to Cloud Run.

Event format and libraries

Eventarc delivers events, regardless of source, to the target Cloud Run service in a CloudEvents format using an HTTP request in binary content mode. CloudEvents is a specification for describing event metadata in a common way, under the Cloud Native Computing Foundation and organized by the foundation's Serverless Working Group.

Using a standard way to describe event metadata ensures consistency, accessibility, and portability. Event consumers can read these events directly, or you can use Google CloudEvents SDKs and libraries in various languages (including C#, Go, Java, Node.js, and Python) to read and parse the events:

Eventarc parsing libraries

The structure of the HTTP body for all events is available in the Google CloudEvents GitHub repository. For more information, see Develop event receivers.

Eventarc triggers

Events occur whether or not you choose to respond to them. You create a response to an event with a trigger. A trigger is a declaration that you are interested in a certain event or set of events, and binding a Cloud Run service to a trigger allows you to capture and act on specific events. For more information, see Create a trigger and the REST representation of a trigger resource.

Eventarc supports these trigger types:

Cloud Audit Logs (CAL) events
DescriptionCloud Audit Logs provide Admin Activity and Data Access audit logs for each Cloud project, folder, and organization. Google Cloud services write entries to these logs. This list of supported events includes a directory of serviceName and methodName values.
Event filter typeEventarc triggers with type=google.cloud.audit.log.v1.written send requests to your Cloud Run service when an audit log is created that matches the trigger's filter criteria.
Cloud Pub/Sub events
DescriptionEventarc can be triggered by messages published to Pub/Sub topics. Pub/Sub is a globally distributed message bus that automatically scales as you need it. Because Eventarc can be invoked by messages on a Pub/Sub topic, you can easily integrate Eventarc with any other service that supports Pub/Sub as a destination.
Event filter typeEventarc triggers with type=google.cloud.pubsub.topic.v1.messagePublished send requests to your Cloud Run service when a message is published to the specified trigger topic.
Cloud Storage events
DescriptionEventarc can be triggered by various events inside a Cloud Storage bucket—object creation, deletion, archiving, and metadata updates.
Event filter typeEventarc triggers with type=google.cloud.storage.object.v1.finalized, type=google.cloud.storage.object.v1.archived, type=google.cloud.storage.object.v1.deleted, or type=google.cloud.storage.object.v1.metadataUpdated send requests to your Cloud Run service when an event occurs that matches the trigger's filter criteria.

Trigger location

Google Cloud services such as Cloud Storage can be set up to be regional or multi-regional. Some services, such as Cloud Build can be set up globally.

Eventarc lets you create regional triggers or you can create a global trigger (only applicable to Cloud Audit Logs triggers) and receive events from all regions. For more information, see Eventarc locations.

You should specify the location of the Eventarc trigger to match the location of the Google Cloud service that is generating events and avoid any performance and data residency issues caused by a global trigger.

You can specify trigger locations using a --location flag with each command. If a --destination-run-region flag is not specified, it is assumed that the service is in the same region as the trigger. For more information, see the gcloud command-line tool Reference.

Reliability and delivery

Delivery expectations are as follows:

  • Events using Cloud Audit Logs are delivered in under a minute.
  • Events using Pub/Sub are delivered in seconds.

There is no in-order, first-in-first-out delivery guarantee. Note that having strict ordering would undermine Eventarc's availability and scalability features which match those of its transport layer, Cloud Pub/Sub. For more information, see Ordering messages.

Latency and throughput are best effort. They vary based on multiple factors, including whether the Eventarc trigger is regional, multi-regional, or global; the configuration of a particular service; and the network load on resources in a Google Cloud region.

Note that there are usage quotas and limits that apply to Eventarc when used with Cloud Run.

Event retry policy

Event issuing failures are automatically retried, except for errors that do not warrant retries. This matches the retry characteristics of Eventarc's transport layer, Cloud Pub/Sub. If the Cloud Run service is not acknowledging messages, Pub/Sub retains events for seven days by default and will retry sending events to the target. For more information, see Pub/Sub resource limits.


Detailed logs are available from:

What's next