This endpoint returns the time-stamped availability change events that occurred for the organization's devices in the requested timespan, and is intended to be a hyper-efficient means of monitoring device availabilities. You can get started by calling:
GET /organizations/:organizationId/devices/availabilities/changeHistory
An empty result means there were no availability changes for any device in that organization for that timespan.
Default timespan is 1 day; maximum timespan is 14 days. Aside from the standard t0/t1/timespan controls, other filters include:
productTypes[]
networkIds[]
serials[]
statuses[]
Here's an example response, indicating that a single MV device changed from online > offline status, and subsequently changed back online status about 2 days later. It also indicates that no other device in the organization had any change in availability for that timespan.
This can be used for many purposes, such as:
Thanks to our Early API Access community for your valuable feedback during beta! This endpoint is now GA and we look forward to hearing how this new endpoint helps to streamline your workflows.
Hi, @John-K. Can you clarify if this shows every availability (status) change during the given time frame? For example, if a device were connected from 12:01AM to 9AM, then disconnected between 9AM and 3PM, then connected again from 3PM to 7PM, and finally disconnected for the remainder of the day... what would this endpoint tell us about the device?
Thanks so much!
Hi @Prodrick ! You'll see all the changes:
1. The first change at ~9am to offline
2. The second change ~3pm to online
3. The final change ~7pm to offline
You'll also see change events for that device if at any point in the process it was in "alerting" status.
I love it!!! Thanks @John-K. Since this is an org-level call, might this be a precursor to being able to get all events at the org-level without having to make network-level calls? I ask because we have customers with thousands of networks where it's rate-limit prohibitive to use the network-level events endpoints.
Is this live in 135?
The change history endpoint is live on all shards.
Which events endpoint(s) would you like to see aggregated at the organization level?
Hi, @John-K. This is the one I have my eye on, but it's expensive to make on a per-network call if you have thousands of networks. However, If I could make per-org calls every 5-10 minutes to get these in bulk they'd be super valuable.
https://api.meraki.com/api/v1/networks/:networkId/events
Perhaps having it similar to this:
https://api.meraki.com/api/v1/organizations/:organizationId/appliance/security/events
However, I suspect that it these uber-large orgs we might have to do lots of paging if it's limited to 1000 per call. I'll DM you with the customer-specific info, as there are two extremely large global Meraki Orgs that I have in mind for this.
Throwing my hat in for this one as well. An org-level event log would be excellent.
Another that could benefit from org-level aggregation would be:
https://api.meraki.com/api/v1/networks/$networkId/health/alerts
Catching up on testing after covid, this post has been edited as I went along...
The old/new details arrays can differ in size, either can be zero, I've not seen either >2
The only time I see size >1 is where the first element just says it's an alert, and the second says what the alert is/was.
As the call is GA now, probably too late, but if it were me I'd have simplified and put the alert description in the value rather than have detail arrays.
Or are there other instances where array will be >1 ?
total elements | timestamp | modell | old name | old value | new name | new value |
4 | 2023-07-19T21:17:25.795000Z | MS350-48LP | status | alerting | status | alerting |
4 | 2023-07-19T21:17:25.795000Z | MS350-48LP | alert | DHCP failure on management VLAN | alert | Disabled gateway (bad DNS) |
4 | 2023-07-19T21:17:25.779999Z | MS350-48LP | status | alerting | status | alerting |
4 | 2023-07-19T21:17:25.779999Z | MS350-48LP | alert | DHCP failure on management VLAN | alert | Disabled gateway (bad DNS) |
3 | 2023-07-19T23:59:07.091000Z | MS350-48LP | status | online | status | alerting |
3 | 2023-07-19T23:59:07.091000Z | MS350-48LP | alert | DHCP failure on management VLAN | ||
3 | 2023-07-19T23:59:07.036999Z | MS350-48LP | status | online | status | alerting |
3 | 2023-07-19T23:59:07.036999Z | MS350-48LP | alert | DHCP failure on management VLAN | ||
3 | 2023-07-19T21:19:29.835000Z | MS350-48LP | status | alerting | status | online |
3 | 2023-07-19T21:19:29.835000Z | MS350-48LP | alert | Disabled gateway (bad DNS) | ||
3 | 2023-07-19T21:19:29.818000Z | MS350-48LP | status | alerting | status | online |
3 | 2023-07-19T21:19:29.818000Z | MS350-48LP | alert | Disabled gateway (bad DNS) | ||
3 | 2023-07-19T21:18:30.970999Z | MX67 | status | alerting | status | online |
3 | 2023-07-19T21:18:30.970999Z | MX67 | alert | Disabled gateway (bad DNS) | ||
3 | 2023-07-19T21:18:15.997999Z | MX67 | status | offline | status | alerting |
3 | 2023-07-19T21:18:15.997999Z | MX67 | alert | Disabled gateway (bad DNS) | ||
3 | 2023-07-19T21:17:25.653000Z | MS350-48LP | status | alerting | status | online |
3 | 2023-07-19T21:17:25.653000Z | MS350-48LP | alert | DHCP failure on management VLAN |