What does the Cleveland OH 311 data include?

One table, service requests, with one row per service request.

Do I need an account with Cleveland OH 311?

No. The data is public, so there is nothing to sign up for and nothing to paste in.

How fresh is the data?

As fresh as your schedule: daily by default, or weekly or monthly. Schedules as often as every 15 minutes are on the Enterprise plan. Each run replaces the table with a fresh copy, so edits and removals at the source show up after the next run.

Will running it again create duplicate rows?

No. Each run replaces the table, so it never holds two copies of the same row.

Do I need to write code?

No. Ingest builds, runs and maintains the connector. Someone with access to your warehouse connects it once, following a short guide.

Cleveland OH 311

Public data

Ready to useNo account needed

Service requests reported to Cleveland, Ohio's 311 line since February 2024, as the city publishes them. Ingest delivers this data to a data warehouse you own as one table, and updates it on the schedule you choose. There is no code to write and nothing to install.

177,925service requests as of September 2026
About 2,200new service requests a week
1 tableone row per service request

What people use it for

Compare demand by wardSee which wards report the most requests and how that changes over time.
Track how long requests take to closeCompare when a request is made against its target date and closing date.
Map where requests come fromPlot requests using their coordinates to see where they cluster.

What you get

Table	Each row is
Service requests `featureserver`	One service request

Good to know

Each run replaces the table with a fresh copy, so edits and removals at the source show up after the next run.

How it works

Choose Cleveland OH 311. The data is public, so there is nothing to sign in to.
Pick where it goes. BigQuery, Snowflake, Databricks, Redshift and 10 more, in an account you own.
Pick a schedule. Daily is the default, and weekly and monthly are there too.
Ingest runs it from then on. If a run fails, your dashboard shows which table and why.

Questions

What does the Cleveland OH 311 data include?: One table, service requests, with one row per service request.
Do I need an account with Cleveland OH 311?: No. The data is public, so there is nothing to sign up for and nothing to paste in.
Which warehouses can Cleveland OH 311 data go to?: Amazon S3, Google Cloud Storage, Azure Blob Storage, Apache Iceberg, Ingest Managed Lakehouse, MotherDuck, Postgres, Amazon Athena, Databricks, Redshift, BigQuery, ClickHouse, MySQL / generic SQL and Snowflake, in an account you own.
How fresh is the data?: As fresh as your schedule: daily by default, or weekly or monthly. Schedules as often as every 15 minutes are on the Enterprise plan. Each run replaces the table with a fresh copy, so edits and removals at the source show up after the next run.
Will running it again create duplicate rows?: No. Each run replaces the table, so it never holds two copies of the same row.
Do I need to write code?: No. Ingest builds, runs and maintains the connector. Someone with access to your warehouse connects it once, following a short guide.

For your data team: technical reference

Connector cleveland_311, version 0.1.0, a REST source, status beta, authentication none.

Vendor documentation: https://services3.arcgis.com/dty2kHktVXHrqO8i/arcgis/rest/services/Data_311/FeatureServer/0

Configuration

No configuration required.

Resources

Resource	Status	Plan	Write	Primary key	Overrides
`featureserver` All Cleveland 311 public service requests exposed by the city's Data_311 ArcGIS layer. The publisher scopes this feed to requests from February 29, 2024 onward; older requests are archived separately, so the connector does not claim full history of the city's 311 records. Each run replaces the destination with the current layer snapshot: records removed from the source are removed, and later edits (updated statuses, added closures) appear on the next run. ArcGIS native Date fields (requested_datetime, updated_datetime, closed_date, target_date) arrive as integer epoch milliseconds in UTC and are preserved as bigint; interpret the value as milliseconds since the Unix epoch. Per the publisher, some closed_date values from before the September 4, 2024 system launch may be later than the actual closure; updated_datetime is exposed for reference. The full exposed collection measured 177,925 records on 2026-09-14 and fits a single run under the connector's recorded limits.	beta	full	replace	`service_request_id`	-